Python 3 Transition Plan / Calendar Versioning
André Sintzoff
andre.sintzoff at gmail.com
Tue Oct 15 18:47:24 UTC 2019
Le mer. 9 oct. 2019 à 03:30, Gregory Szorc <gregory.szorc at gmail.com> a écrit :
>
> Our new versioning scheme will be YYYY.[M]M.N. e.g. 2020.5.0 or 2020.10.1. This scheme consists of the 4 digit year, a 1-2 digit month, and a monotonically increasing point release, starting at 0. This scheme is compatible with our existing versioning scheme, has a major version that is greater than 5, and doesn't have a leading 0 in the month field (which could confuse version parsers).
With new versioning scheme, what is the meaning of [M]M modification?
Is it only calendar based or is it feature based?
Will the sequence be:
2020.2.0 (feature release)
2020.3.0 (bugfix release)
2020.4.0 (bugfix release)
2020.5.0 (feature release)
or
2020.2.0 (feature release)
2020.2.1 (bugfix release)
2020.2.2 (bugfix release)
2020.5.0 (feature release)
I'm asking this because people waiting the first bugfix release before updating.
Depending on the sequence, it will be very difficult for users to know
if a release is a bug fix one or a feature one.
According to the 5.2 Sprint Notes, there was a discussion regarding
the cadence of the feature releases.
Personally, I would prefer to keep quarterly feature releases for normal users.
Is there any planned change?
Thanks
André
More information about the Mercurial-packaging
mailing list