| ... | ... | @@ -162,9 +162,12 @@ The `main` branch contains the last stable version of openPASS. Thus, the `main` |
|
|
|
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.
|
|
|
|
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. Update the link to the pre-built version on the webpage.
|
|
|
|
4. Webpage updates:
|
|
|
|
- Update the link to the pre-built version on the webpage.
|
|
|
|
- Update the download link
|
|
|
|
- Update the timeline with the new version
|
|
|
|
5. Afterwards, the documentation has to be updated.
|
|
|
|
|
|
|
|
## Update of Documentation
|
| ... | ... | |
