Use of release candidate tags / tidy up historic tags

Recently, I have been running GS2 using the 8.0.2-RC branch.

I just ran git fetch and saw the output:

1a5ea5aa..7cb03b5e 8.0.2-RC -> origin/8.0.2-RC
meaning that the 8.0.2-RC branch has been updated. Fair enough. But…

For comparison, the repository of the git program has the following tags for it’s latest version:

v2.21.0
v2.21.0-rc0
v2.21.0-rc1
v2.21.0-rc2

May I suggest that we have a (potentially short lived) release branch (as we currently have), but we also tag particular commits on that branch as the actual candidates for release. This will make it more obvious which commits represents release candidates and which are intermediate (probably bug fix) commits, thus facilitating testing and discussion of release candidates (we can refer to v8.0.2-rc0, v8.0.2-rc1, etc. instead of 1a5ea5aa, 7cb03b5e, etc., we can revert to previous release candidates more easily, etc). This will also keep the release candidates around after the release branch has gone.

While we’re at it, can we tidy up the historic tags from this:

6.0
6.0.0
6.0.1
7.0
8.0
8.0.1
release-2.0
release-2.1
release-3.0
release-3.1
release-3.2
release-4.0
release-4.0.7
release-5.3
release-5.4
release-5.4.1
release_candidate
v8.0.1

to this:

~~release-2.0~~ → v2.0
~~release-2.1~~ → v2.1
~~release-3.0~~ → v3.0
~~release-3.1~~ → v3.1
~~release-3.2~~ → v3.2
~~release-4.0~~ → v4.0
~~release-4.0.7~~ → v4.0.7
~~release-5.3~~ → v5.3
~~release-5.4~~→ v5.4
~~release-5.4.1~~ → v5.4.1
~~6.0~~ (neither a release nor a release candidate)
~~release_candidate~~ (duplicate)
~~6.0.0~~ → v6.0.0
~~6.0.1~~ → v6.0.1
~~7.0~~ → v7.0
~~8.0~~ → v8.0
v8.0.1
~~8.0.1~~ (duplicate)
v8.0.2-rc0
v8.0.2-rc1

I think it’s important to have tags like this because it puts versions in order making it easier to find stuff, and it is fairly standard across software projects so it is what new users / developers will expect and thus will make it easy for people to find a particular release version / candidate. Plus the other benefits mentioned above for existing developers.

Comments (1)