Python 3 Transition Plan / Calendar Versioning

Gregory Szorc gregory.szorc at gmail.com
Wed Oct 9 01:26:46 UTC 2019


At the Mercurial 5.2 Sprint last weekend, we made a number of decisions
regarding Python 3 and version numbers.

Our plan is to make Mercurial 5.2 (the next release planned for November 1)
stable on Python 3 on all major platforms. This entails Mercurial passing
as many tests as a Python 2.7 based Mercurial currently does on those
platforms.

As for which versions of Python 3 to support, ideally we support 3.5-3.8.
However, on environments like Windows where Mercurial is typically
distributed with a copy of Python, we may only officially support the most
modern version(s) of stable Python (currently 3.7) if supporting older
Python versions on those platforms is too much effort.

We are asking packagers to switch the Python that is distributed with
Mercurial or that Mercurial uses by default to the most modern version of
Python 3 you can with the 5.2 release.

However, we may perform the initial 5.2 release with Python 2.7 and then
perform a point release or another major version release a few weeks later
targeting Python 3 as the primary/preferred Python. We haven't yet decided.
It may depend on various timetables. So our advice for packagers is to
support packaging 5.2 with both Python 2 and 3 and to be prepared to
release both variants, possibly just days apart.

Once a Python 3 stable release is shipped, we want to drop Python 2 as soon
as possible. This will be gated by various large Mercurial users confirming
that Python 3 Mercurial is working for them. We anticipate that the first
major planned release on February 1, 2020 will still support Python 2.7 and
we'll drop Python 2.7 support in the release planned for May 1, 2020.
Although if things go exceedingly well with the transition, we may drop
Python 2.7 support in the February 1, 2020 release. (We all want to drop
Python 2.7 as soon as possible but we don't want to cause excessive harm to
our users.)

I referred to the releases by calendar date because at the 5.2 Sprint we
decided to adopt calendar versioning starting with the first Mercurial
release that is Python 3 only.

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).

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.

Please reply to mercurial-packaging@ and mercurial-devel@ if you have any
questions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-packaging/attachments/20191008/fcf2ddeb/attachment.html>


More information about the Mercurial-packaging mailing list