ynkmr/Sourcetrail
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Created Version Numbers (markdown)

Malte Langkabel
2019-11-25 19:05:09 +01:00
parent 9fcf649300
commit 8f16018ed7
1 changed files with 10 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Version-Numbers.md
+10
@@ -0,0 +1,10 @@
Sourcetrail maintains a quarterly release schedule. Thus the format for our version numbers is `YYYY.Q.C`, where
* `YYYY`is 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`_.