| ... | ... | @@ -154,44 +154,3 @@ The DoD defines all requirements that need to be fulfilled for a contribution. A |
|
|
|
- Copyright Headers are updated
|
|
|
|
- Contribution Questionnaires (CQ) for new third party dependencies are created and approved
|
|
|
|
- Code has been formatted automatically using clang format |
|
|
|
|
|
|
|
## 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:
|
|
|
|
|
|
|
|
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 (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. Create a release on the Eclipse openPASS project page (https://projects.eclipse.org/projects/automotive.openpass)
|
|
|
|
1. Webpage updates:
|
|
|
|
- Update the download link (https://openpass.eclipse.org/)
|
|
|
|
- Update the timeline with the new version (https://openpass.eclipse.org/working-group/#timeline)
|
|
|
|
1. Afterwards, the documentation has to be updated.
|
|
|
|
|
|
|
|
## Update of 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
|
|
|
|
The Git server hosting the documentation can be found here: https://git.eclipse.org/c/www.eclipse.org/openpass.git/.
|
|
|
|
|
|
|
|
- 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\“
|
|
|
|
- Commit 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 |
|
|
\ No newline at end of file |
