| ... | ... | @@ -179,9 +179,33 @@ The DoD defines all requirements that need to be fulfilled for a contribution. A |
|
|
|
|
|
|
|
## Guideline: Steps towards a new release
|
|
|
|
|
|
|
|
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:
|
|
|
|
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.
|
|
|
|
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 with the according version number. The release date is set by tacking the version number. |
|
|
\ No newline at end of file |
|
|
|
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.
|
|
|
|
5. Afterwards, the documentation has to be updated.
|
|
|
|
## Update the Documentation
|
|
|
|
|
|
|
|
Step 1 is usually done by a committer. Step 2 should be done by the project lead.
|
|
|
|
|
|
|
|
### 1. Build documentation
|
|
|
|
- Clone sources of openPASS
|
|
|
|
- Installation of necessary tools (MSYS2, MinGW, etc.) https://www.eclipse.org/simopenpass/content/html/installation_guide/20_install_prerequisites.html
|
|
|
|
- Build documentation from MSYS2-MINGW64-shell
|
|
|
|
- mkdir build && cd build
|
|
|
|
- cmake -G "MinGW Makefiles" -DWITH_SIMCORE=OFF -DWITH_TESTS=OFF -DWITH_DOC=ON ..
|
|
|
|
- mingw32-make doc
|
|
|
|
- A "html" folder with the documentation is being created
|
|
|
|
|
|
|
|
### 2. Update documentation on the Eclipse server
|
|
|
|
- Clone sources of the documentation page: git clone ssh://username@git.eclipse.org:29418/www.eclipse.org/simopenpass.git
|
|
|
|
- Delete folder "<REPO>\content\html\“
|
|
|
|
- Add new documentation into "<REPO>\content\html\“
|
|
|
|
- Committ and push (directly into "master"):
|
|
|
|
- git add -A ("add everything")
|
|
|
|
- git commit -m "commit message"
|
|
|
|
- git push
|
|
|
|
- The documentation is automatically linked on the openPASS webpages
|
|
|
|
|
