Open m-ueberall opened 4 years ago
v0.6.21
is the stable one that we use in production. Anything that uses -rcN
is a Release Candidate (not stable). Hence the stable version of v0.6.21-rc2
will be v0.6.22
(once released).
The branch v0.6
is continuously updated and from that, the releases of v0.6.x
are being produced. Once it is in a good state and tested, there is an RC release. The branch v0.7
was supposed to contain fundamental changes and therefore it needed a separate development workflow. Eventually, the fixes of v0.6
would also go to v0.7
.
fwiw, I was confused about the first point as well (a release candidate coming after a release). Typically, v0.6.21-rc2
will come before v0.6.21
.
I for one find it quite difficult to identify the latest stable release:
v0.6.21
published on the 4th of November, followed byv0.6.21-rc2
published on the 21st of the same month.vX.Y.Z[-rcN]
, but not that many branches.(1) Does the above mean that release v0.6.21 has effectively been retracted? (From my experience, releases to be used in production environments don't come with
rc
suffixes.) (2) Is it possible to align releases and tags (e.g. by introducingv0.6.22
) and clarify the terse reference to "branches" (or rather tags which represent a version of a particular branch at a moment in time)? By definition, branches represent separate threads of development regardless of their naming/versioning, of course, but a short overview of state/relationships/features in the README might really come in handy.