Version Numbers

Sourcetrail maintains a quarterly release schedule. Thus the format for our version numbers is YYYY.Q.C, where

• YYYYis the year of the release
• Q is the quarter of the release
• C is the count of the commit that was used to build the release.

The count re-starts at 0 on every annotated tag. Thus, after a quarterly release has been deployed (e.g. 2019.4.61 on 18th November 2019) immediately a new annotated tag is created on GitHub (2020.1). If you would build a Sourcetrail version on this tag, our scripts would assign the version number 2020.1.0. However, as version 2019.4.61 has just been released, the 2020.1 tag on Github won't have any release builds associated with it.

As development goes on, the version number automatically increases, until at some time during the 1st quarter of 2020 the next release is deployed. At this point, a tag 2020.1-r1 will be created on GitHub without annotations and the release builds of that commit will be uploaded. In addition the annotated tag 2020.2 is created and the cycle starts again.

If there would be fixes during the work on the 2020.2 release that should still be available in the 2020.1 release, we would crate a release branch, starting at tag 2020.1-rc and pull the relevant commits. Once all those commits have been pulled a new non-annotated tag 2020.1-r2 is created on that branch and the releases will be uploaded to GitHub again. Note, that the commit count would still start at the lase annotated tag, which would be 2020.1.