This covers various project policies and practices.
While I license this code using the GNU GPL, Version 3 or later, I currently hold exclusive copyright to the base contribution. For the purpose of any external contributions, should that actually happen, we will use a DSO, much like the Linux Foundation does.
2. Release Tags
A release is made thru a tag. This also updates generated documentation as well. When we do public releases the release tag will be signed by the project owner. A release tag is a deliverable unit, and so may be the output of a sprint. A new major release is tied to closure of all associated milestones for that release. When we do a major release we may also consolidate the changelog for major releases only.
When a new release tag is made, the project should be updated to the next (future) expected release. This means the next release should be added at the top of the CHANGELOG file, and the release version in CMakeLists should both be updated, before new work begins.
3. Patch Releases
Patch releases happen when we have to do emergency bugfixes for a past major release. This would be done by opening a patch release branch from the last used tag in that release series. The .gitlab-ci.yml must be modified to disable pages, as we do not want to generate the public documentation based on old release series when we make tags. Bug fixes can then be made, or cherry-picked, into the patch release branch, and new tags made as needed for patch releases.