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
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
