Cosmetics

pages/06.contribute/10.packaging_apps/14.advanced/03.packaging_v2/packaging_v2.md

@@ -37,25 +37,25 @@ This will edit the file in place and you should then carefully review and iterat
 
 ### Highlights of the new format
 
-- The manifest is now written as toml (`manifest.toml`) instead of json (`manifest.json`). The structure of the manifest itself has been reworked and now include:
+- **The manifest is now written as toml (`manifest.toml`)** instead of json (`manifest.json`). The structure of the manifest itself has been reworked and now include:
    - The `upstream` section (now mandatory)
    - An `integration` section meant to formalize what minimum yunohost version is required, the list of supported architectures, declare if SSO/LDAP is supported, typical resource usage. This is meant to be displayed both in the catalog (similar to app stores) and on the app info page after installing the app - though this is still work in progress. 
    - A `resource` section (detailed below)
-- Install questions are now automatically saved as settings (except user-provided password and other specific infos)
+- **Install questions are now automatically saved as settings** (except user-provided password and other specific infos)
-- All settings are now automatically loaded in app script environments (so e.g. directly define `$domain`, etc.)
+- **All settings are now automatically loaded in app script environments** (so e.g. directly define `$domain`, etc.)
-- Auto-enable `set -eu` aka `ynh_abort_if_errors` in appropriate scripts
+- **Auto-enable `set -eu`** a.k.a. `ynh_abort_if_errors` in appropriate scripts
-- The safety-backup-before-upgrade is now automatically handled by the core
+- **The safety-backup-before-upgrade is now automatically handled by the core**
-- Introduce a new `resource` mechanism to formalize some steps and handle them from the core. 
+- **Introduce a new `resource` mechanism**
     - Resources are declared in the `manifest.toml`. 
     - They are meant to formalize recurring app needs that are to be provisioned/deprovisioned by the core. 
     - They include for example : system user, apt dependencies, install dir, data dir, port, permissions, SQL database ... 
     - Each resource is to be provisioned *before* running the install script, deprovisioned *after* the remove script, and automatically upgraded if needed before running the upgrade script (or provisionned if introduced in the new app version, or deprovisioned if removed w.r.t. the previous app version)
     - More infos about resources and their options and behavior are available in the dedicated doc page
-- Permissions are to be initialized using the answer to the `init_main_permission` install question (replacing the `is_public` question). No need to write a boring `if $is_public ...` to add visitors ! There is a similar mechanism to init other permissions, eg `init_admin_permission` (cf also the doc about the `permission` resource)
+- **Permissions are automatically initialized using the answer to the `init_main_permission` install question** (replacing the `is_public` question). No need to write a boring `if $is_public ...` in the install script to add visitors anymore ! There is a similar mechanism to init other permissions, eg `init_admin_permission` (cf also the doc about the `permission` resource)
-- The content of the `doc/` folder is now meant to be integrated in the webadmin (though this is still WIP as of writing this). In particular:
+- **The content of the `doc/` folder is now meant to be integrated in the webadmin** (though this is still WIP as of writing this). In particular:
     - `DESCRIPTION.md` and the `screenshots/` folder are expected to be displayed prior to the app install form (similar to app stores on mobile)
     - `ADMIN.md` is expected to be made available somewhere in the info page and should contain technical admin notes. Other pages can be defined (just name it `WHATEVER.md`). Lang codes are also supported following the existing scheme for the README, eg `README_fr.md` is the french version, hence you can create `ADMIN_fr.md`, etc.
-- The content of the `doc/notification/` folder is meant to replace the `ynh_send_readme_to_admin` mechanics. The integration of these in the webadmin is still work in progress. You can create:
+- **The content of the `doc/notification/` folder is meant to replace the `ynh_send_readme_to_admin` mechanics**. The integration of these in the webadmin is still work in progress. You can create:
     - `doc/notifications/pre_install.md` : a note to be displayed prior to the app install. Typically to warn of something unusual, such as "the app install will automatically add 1GB swap to the system".
     - `doc/notifications/post_install.md` : a note to be displayed after the app install. Typically to explain post-install operations to be performed manually by the admin and that cannot be automated.
     - `doc/notifications/pre_upgrade.md` : a note to be displayed prior to any upgrade of this app.