Python 3 Transition Plan / Calendar Versioning

[Gregory Szorc]

On Wed, Oct 16, 2019 at 1:09 AM David Demelier <markand at malikania.fr> wrote:

> 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:
>

Mercurial's existing versioning scheme means little to nothing and is
arbitrary. A calendar versioning scheme is equally arbitrary.

Mercurial has not guaranteed internal API stability in recent memory.
Attempting to tie versions to internal APIs does not make sense.

Mercurial does have pretty strong guarantees around command line behavior.
But the only guarantees here are any major release (currently X.Y) can
break things. Although it is rare for major changes.

You advocate for use of semantic versioning. But this doesn't make sense
given Mercurial's API/CLI contract coupled with our date-based release
schedule, which as Augie says has been good for the project.

If Mercurial someday offers a more stable API, semantic versioning would
make more sense. But we're not even close to it today and it therefore
doesn't make sense. Again, version numbers are arbitrary. Mercurial's
switch to a calendar based versioning scheme is effectively repainting the
bike shed from red to blue.


>
> 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 at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20191016/757e7629/attachment.html>