wip mark parts of doc to rewrite

docs/dev/launch-a-live-network.md

@@ -15,7 +15,7 @@ When launching a new network, you're likely to use a new runtime. See how to [re
 
 ### Inject runtime in chainspec
 
-ĞDev runtime is automatically embeded in the raw chainspec with the `include_bytes!` macro. An other way to inject the runtime is to use "inject-runtime-code" xtask:
+~~ĞDev runtime is automatically embeded in the raw chainspec with the `include_bytes!` macro. An other way~~ to inject the runtime is to use "inject-runtime-code" xtask:
 
 ```bash
 cargo xtask inject-runtime-code --runtime runtime/gdev/target/srtool/release/wbuild/gdev-runtime/gdev_runtime.compact.compressed.wasm --raw-spec resources/gdev-raw.json

docs/dev/release-new-runtime.md

@@ -10,12 +10,14 @@ Example for `runtime-800`.
 
 ### New release with new Runtime
 
-* create a `release/runtime-800` branch locally
-* update the values:
-  * update spec version (in `runtime/<currency>/src/lib.rs`)
-  * eventually update `gdev.yml` (smiths, tech. committee, ...)
-* push the `release/runtime-800` branch
-  * in the CI/CD, wait for `Create release` button to be available and click on it (see above screenshot)
+- create a `release/runtime-800` branch locally [FIXME network/gdev-800]
+- update the values:
+  - update spec version (in `runtime/<currency>/src/lib.rs`)
+  - eventually update `gdev.yml` (smiths, tech. committee, ...) [FIXME this should be only for bootstraping new network]
+  - [+ update the Cargo.lock file]
+  - [+ FIXME milestones should be updated before that]
+- push the `release/runtime-800` branch
+  - in the CI/CD, wait for `Create release` button to be available and click on it (see above screenshot)
 
 The Runtime is now available on the release page [runtime-800](https://git.duniter.org/nodes/rust/duniter-v2s/-/releases/runtime-800).
 
@@ -24,30 +26,33 @@ The Runtime is now available on the release page [runtime-800](https://git.dunit
 The Client is published as a Docker image.
 
 You may want to publish a new Client version along with a Runtime update.
+[NOTE only necessary in the case of breaking changes in the API]
 
 #### New raw specs (optional)
 
+[FIXME we should split the release runtime doc and the bootstrap network doc]
+
 For a reboot, you will likely want to update the raw specs:
 
-* in the CI/CD, wait for `release_gdev_specs` button to be available and click on it
-* in the CI/CD, wait for `release_gtest_specs` button to be available and click on it
-* wait for both jobs to finish
-* update the Client raw specs with `cargo xtask update-raw-specs runtime-800`
+- in the CI/CD, wait for `release_gdev_specs` button to be available and click on it
+- in the CI/CD, wait for `release_gtest_specs` button to be available and click on it
+- wait for both jobs to finish
+- update the Client raw specs with `cargo xtask update-raw-specs runtime-800`
 
 #### New version (mandatory)
 
 Update Client values:
 
-* update Client version (in `Cargo.toml`)
-* update `Cargo.lock` with `cargo build`
+- update Client version (in `Cargo.toml`)
+- update `Cargo.lock` with `cargo build`
 
 #### Publish Docker image
 
 Commit everything and push the branch:
 
-* in the CI/CD, a new pipeline has been launched
-* you can stop jobs `create_g1_data`, `gdev_srtool`, `gtest_srtool` (won't be used)
-* click on `gdev_docker_deploy` and `gtest_docker_deploy`
+- in the CI/CD, a new pipeline has been launched
+- you can stop jobs `create_g1_data`, `gdev_srtool`, `gtest_srtool` (won't be used)
+- click on `gdev_docker_deploy` and `gtest_docker_deploy`
 
 The Docker images should now be available at: https://hub.docker.com/r/duniter/duniter-v2s-gdev/tags.
 
@@ -56,3 +61,7 @@ The Docker images should now be available at: https://hub.docker.com/r/duniter/d
 Our runtime tags use `xxyy` version numbers where `x` corresponds to major change and `y` hotfix.
 
 Make sure to move any issue or merge request assigned to the choosen milestone `runtime-xxyy` to the next one. This prevents from forgetting unfinished work.
+
+## Submit the runtime upgrade proposal
+
+Releasing a new runtime creates a Gitlab release page which contains everything needed to submit a runtime upgrade proposal and upload the new runtime when it gets accepted.