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