Python 3 Transition Plan / Calendar Versioning

[David Demelier]

Le 09/10/2019 à 03:26, Gregory Szorc 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).

Please don't

Dates are not an appropriate versioning scheme. The only sane versioning 
scheme is Semantic Versioning [0] which guarantees API compatibility in:

1. Mercurial internal API. Just look how many developers hated with 
passion that Mercurial breaks its API making external extensions very 
painful to write ;
2. User change. We currently have a strong backward compatibility that 
we keep like a ball and chain since decades because we explicitly say 
that we don't want to break existing tooling. But this refrain ourselves 
of going ahead and change things, cleanup them and make better things. 
The example of hg grep is a good candidate for this ;
3. Stable releases in distributions. Many distributions fail to deliver 
Mercurial + TortoiseHg together because they are mostly tied in their 
versions and often TortoiseHg is being broken because Mercurial is no 
longer API compatible with.

All theses issues are no longer existing with proper Semantic 
Versioning. Also, imagine the following scenario using dates:

In February, you release the hypothetical Mercurial 5.2 named 
2020.02.dd. Fine.

In March, we realized there is a bug important to be fixed, we need to 
release a simple bugfix version with absolutely no user visible change. 
You release it as 2020.03.dd. Not fine.

In June, we implement a new feature that is still API compatible however 
it may provide more power to the user and start deprecating things. You 
release it as 2020.05.dd. Absolutely not fine.

So during 2020, you'll have 2020.02.dd, 2020.03.dd, 2020.05.dd without 
any information on which version is supposed to still be compatible or 
being a simple bugfix release. Having to search the changelog in details 
to see if you can upgrade or not in your distribution.

Dates are simply not the correct way to mark a version. Especially since 
features, bugs, incompatibilities are not fixed at specific time points.

And I personally would like to see a Mercurial 6.y.z version where we 
could remove all deprecated things for a good time. I also don't 
understand why we keep creating releases at specific dates while not 
just release “once it's ready”.

To be honest, the only area where dates are appropriates is about 
providing pure data. Example: SSL certificates, timezones information. 
And that's also almost the only package on my Linux distributions that 
are versioned with dates.

> Succinctly, we decided to adopt calendar versioning because Mercurial's 
> version numbers don't have much semantic meaning and may confuse users 
> who think the major version number changes imply breaking changes. 
> Furthermore, calendar versions may help users better understand how old 
> their Mercurial version is.

And yes, this is exactly because it confuse users that we should follow 
semantic versioning now. Dates are even worse. It's because dates are 
not appropriate that almost no software use them.

[0]: https://semver.org

-- 
David