Home/Developer-Information/Development-Process.md

@@ -160,14 +160,15 @@ The DoD defines all requirements that need to be fulfilled for a contribution. A
 The `main` branch contains the last stable version of openPASS. Thus, the `main` branch is representing the official releases of openPASS and is being tagged accordingly (e.g. v0.7, v0.8, …). New features for the next version are developed in the `develop` branch before they are pushed to the `main` branch. To release a new version within the Eclipse infrastructure, certain steps must be followed:
 
 1. Please read in the [Eclipse handbook](https://www.eclipse.org/projects/handbook/#release) the chapter about releases. The chapter contains detailed information about release reviews which should be performed for each major release. For a minor release it is sufficient to trigger a release review every year. After a successful release review for a minor release, an unlimited number of minor releases can be published for that year.
-2. Release reviews are created as an issue in GitLab. As a reference, the release review for v0.8 can be found [here](https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/85).
-3. After all relevant commits for the new version has been pushed to the `develop` branch, the `develop` branch may be only merged to the `main` branch when the CI is green.
-4. After the merge, the new release is tagged with the according version number. The release date is set by tacking the version number. Add the release notes.
-4. After tagging, a new release has to be created. The release is then associated to the tag, see https://gitlab.eclipse.org/eclipse/openpass/opSimulation/-/releases.
-4. Webpage updates:
-- Update the download link
-- Update the timeline with the new version
-5. Afterwards, the documentation has to be updated.
+1. Release reviews are created as an issue in GitLab. As a reference, the release review for v0.8 can be found [here](https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/85).
+1. After all relevant commits for the new version has been pushed to the `develop` branch, the `develop` branch may be only merged to the `main` branch when the CI is green.
+1. After the merge, the new release is tagged (in git) with the according version number. The release date is set by tacking the version number.
+1. The release has to be built by manually starting the according CI job for the newly assigned tag. After successful completion, artifacts are available on the CI and on https://download.eclipse.org/openpass/release/opSimulation.
+1. After tagging and building, a new release has to be created in GitLab. Release notes can be added here. The release is then associated to the git tag, see https://gitlab.eclipse.org/eclipse/openpass/opSimulation/-/releases.
+1. Webpage updates:
+   - Update the download link
+   - Update the timeline with the new version
+1. Afterwards, the documentation has to be updated.
 
 ## Update of Documentation
 
@@ -188,7 +189,7 @@ The Git server hosting the documentation can be found here: https://git.eclipse.
 - Clone sources of the documentation page: git clone ssh://username@git.eclipse.org:29418/www.eclipse.org/openpass.git
 - Delete folder "<REPO>\content\html\“
 - Add new documentation into "<REPO>\content\html\“
-- Committ and push (directly into "master"):
+- Commit and push (directly into "master"):
   - git add -A ("add everything")
   - git commit -m "commit message"
   - git push