Skip to content

TSF Release Process

TSF releases are scheduled for the 4th Wednesday of every month, with release candidates beginning on the 4th Monday of the month. If there are no meaningful changes i.e. only changes to documentation or CI, a release may not take place; however this should be communicated through the mailing list.

Only committers are able to complete releases, information about becoming a committer can be found here.

Release versions

Releases and release candidate versions are tracked with git tags using a Semantic Versioning 2.0 scheme as follows:

  • Release tags of the form: <MAJOR>.<MINOR>.<PATCH>
  • Release candidate tags of the form: <MAJOR>.<MINOR>.<PATCH>-rc<N>

where:

  • <MAJOR> incompatible API changes
  • <MINOR> backward compatible features
  • <PATCH> backward compatible bug fixes
  • <N> denote release candidates numbers

All are numerical representations (e.g. 0.7.2-rc1).

Releases prior to 0.1 use the CalVer versioning scheme and are considered breaking.

Version 1.0.0 will be the version in which a stable API will be defined.

Release candidates are a means for testing a release before it is finalised. Project users can use the release candidate to test the tooling on their project, reporting back any bugs or breaking changes that occur. If there are a number of bugs, there will be a second release candidate and so forth. If the release candidate is considered acceptable, a full release will follow ~2 days later.

Tooling Interface Stability

The current trudag tool is still in the development stage and therefore cannot be considered as fully stable. However, in favouring stability over constant change, we loosely follow stability rules in practice. The interface surfaces and what should be accounted for in the context of stability are enumerated below:

Dependencies

Any changes to dependencies should only be considered in major releases.

Command Line

Commands and their respective options will not be removed or changed without a major release. New commands and flags should be added in minor release updates.

Artifact

The data model should only change in minor release if additional keys are added in a backwards compatible manner, otherwise changes should only be considered for major releases.

Library

Changes to the public library interface are discouraged in minor releases, however, as the project is in the development stage, may still occur.

Release preparation

  1. Add an issue with the release template to track the release in GitLab.
  2. For a stable release, Create a merge request and update the Release Notes
    • Update docs/NEWS.md to summarise changes, issues resolved, breaking changes and new issues identified
    • Update the package version specified in pyproject.toml to the planned release version
    • Create a tag from the MR branch, with a corresponding release candidate version specifier, and check that the release job runs successfully
    • Verify the generated release package by:
      • Downloading it from the package registry
      • Following the instructions for installing and updating the TSF tools
  3. Create the release
    • Create a release tag on main (see format above) after the release MR has been approved and merged
    • Check that the release has been created and verify the release package
    • Announce the release to the tsf-dev mailing list
    • Update and close the issue