Releases

We use commit-and-tag-version and enforce conventional commits to help with cutting releases and to ensure that we follow semver guidelines.

Automated Releases

The release process of the TALY libraries is semi-automated using a dedicated release pipeline in Jenkins. The table below shows the two types of automated releases.

Trigger	Release type	Channel	Note
Every new commit in `main`	prerelease (`alpha`)	next
Every Tuesday morning	stable release	latest	will not release new major versions

The following subsections explain in more detail when and how a new release is cut and published.

Automated Prereleases

Every push to the main branch results in a new alpha prerelease that gets published as a new next version. This will also publish prereleases of new major versions (i.e. alpha releases that contain breaking changes).
This pipeline will push a release commit (format: chore(release): 1.2.3-alpha.4) to the GitHub repository. It will not tag the commit and it will not write to the CHANGELOG.

Automated Stable Releases

Every tuesday morning there will be a new stable release, also done automatically from inside Jenkins. As a safety measure this pipeline will not publish new major versions, these need to be done manually.
This pipeline will push a release commit (format: chore(release): 1.2.3) to the GitHub repository. It will tag the commit and it will write to the CHANGELOG.
Each stable release is followed by a GitHub release for that tagged commit, happening automatically via a Github workflow triggered every time a tag is pushed.

Semiautomatic Releases

Via the Jenkins UI it is possible to release and publish new versions (stable as well as unstable) at any time by manually triggering the taly-release job by using the Build with parameters button for that job. The build parameter STABLE_RELEASE can be used to specify if the new release should be a stable release or a prerelease. The triggered pipelines behave as described above in Automated prereleases and Automated stable releases.

Manual Releases

There are two scripts that you can use to cut a new release manually: npm run release and npm run release:alpha. Most of the time this will not be necessary since a lot of our releases are automated. See the previous section for details. For major releases we do however strictly require a manual release. This way we make sure that each major release is a very conscious decision that we can time precisely.

If there are commits since the last stable release that contain breaking changes then running npm run release will automatically result in a new major version. The automated release pipelines will never publish a new stable major version.

💡 Manual releases need to be made from a shell that supports the sed command. On Windows we recommend using the Git Bash or a WSL terminal. Linux and MacOS shells will most probably support sed out of the box.

Publishing a New Major Version

💡 Only the TALY core team will release and publish new major versions!

Create a new branch release-x.0.0 from the up-to-date main state.
To publish a new major version a new release needs to be cut manually. Run npm run release, check the automatic commit. Then adjust the CHANGELOG.md file if necessary and add an additional commit.
Push the release branch and open a Pull Request. Make sure the title of the PR starts with chore(release): x.0.0 since this is a necessary marker for Jenkins.
After the PR got merged there will be a new chore(release): x.0.0 commit in main that is waiting to be tagged and published. To do this you can manually trigger the Jenkins taly-release job by using the Build with parameters button for that job. Make sure you tick both build parameters:
- STABLE_RELEASE to publish this new major version on the latest distribution channel.
- PUBLISH_ONLY to not cut a new release but instead use the one that is currently at the HEAD of main.