This is a guide how to make a new CADET release.
For version numbers, we try to orient towards semantic versioning. In summary, given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards compatible manner, and
- PATCH version when you make backwards compatible bug fixes.
For every release, a changelog needs to be provided. For some tips and tricks, see here. Some general aspects:
- Changelogs are for humans, not machines.
- There should be an entry for every single version.
- The same types of changes should be grouped.
- ADDED for new features.
- CHANGED for changes in existing functionality.
- DEPRECATED for soon-to-be removed features.
- REMOVED for now removed features.
- FIXED for any bug fixes.
- SECURITY in case of vulnerabilities.
In the source code, the following files need to be modified:
- CADET/cadet.hpp at master · modsim/CADET · GitHub
- CADET/version.txt at master · modsim/CADET · GitHub
- CADET/cadet.doxyfile at master · modsim/CADET · GitHub
When commiting, add the version in the commit message and also add a tag:
git commit -m 'bump version to MAJOR.MINOR.PATCH' # e.g. 4.3.0 git tag -a 'vMAJOR.MINOR.PATCH' # e.g. v4.3.0 git push origin git push origin --tag
The tag annotation should include the changelog.
Click here to create a new release. Select the corresponding tag and add the changelog. Please ensure that it is nicely formatted using Markdown features.
We’re still working on improving our continuous integration.
Until this is fully implemented, there are still some manual steps to do.
- Add resources (@s.leweke how do I do that?)
- Trigger rebuild of documentation from CADET-Website repository
- Publish on conda (once that works)
- If required, update dependencies for subprojects (CADET-Python, CADET-Process, CADET-Match, etc.)
Also, we should take the opportunity to inform our community about the new release.
- Write newsletter
- Make forum post