N.B. In this context a “release” refers to a version of the TUF implementation; NOT package releases.
Generally, a release will consist of a number of updates from the set of tickets that have been closed and merged since the previous release. We use GitLab’s Merge Request workflow and git branches to track new development, and our Continuous Integration (GitLab CI) validates the full test suite runs successfully as we merge in updates.
Preparing a release is primarily a matter of gathering (and possibly merging)
the various branches that were finished during the release cycle (sprint).
Ideally each of the branches has been merged along the way, and re-incorporated
into new work. If necessary, the release manager will need to resolve conflicts
and ensure all ready branches are merged into the main branch without
breaking the build.
We use Semantic Versioning, so release tags look like
vM.m.p where M is the Major version number, m is the minor version
number, and p is the patch level.
The purpose of tagging a release is to set a marker on the repository at a point in time, to denote a “known state” of the code at that moment. This serves to produce consistent, repeatable builds and deploys.