On 5 November 2017 at 01:29, Wolfgang <tds...@mailbox.org> wrote: > On 04.11.2017 16:01, Nick Coghlan wrote: >> We're currently more likely to go the other direction, and stick with >> the 3.x numbering for an extended period (potentially reaching 3.10, >> 3.11, 3.12, etc), so that the ongoing disruption caused by the 2.x -> >> 3.x transition has had a chance to settle down before we ask anyone to >> start calling anything "Python 4". > > A good point but two digits minor version numbers have the possibility > to break a lot code. There is a lot of stuff out where a single digit > major version is assumed. Even the official Python build for windows > with python27.dll, python36.dll can be problematic because the dot > is omitted between numbers. > Other do the same for compilation they concatenate only majorminor for a > name. > Then version 3.10 is the same as 31.0. > Ok I know this will take a while. > But for the first 2.7.10 version even there some other library code > was broken because of such assumptions.
Aye, we're aware :) We're not in a situation where we'll have any *good* options available, so the question we're considering is "What do we think will be the least bad approach?". At our current release cadence, 3.7 will be in mid 2018, 3.8 in late 2019 or early 2020, and then 3.9 in mid 2021. The open question will be what we call the release after that (in late 2022), with the main leading contenders being "4.0" (on the grounds that so many changes will have accumulated since 2008's 3.0 release by then that it makes sense to call them different major versions, similar to the rationale the Linux kernel now uses for major version updates), and "3.10" (on the grounds that the release won't be any more different from 3.9 than 3.9 will be from 3.8). Other variants (like making the major release number "40" or "2022", and using the minor version field for some new purpose other than indicating compatibility breaks in the compiler AST, interpreter opcode format, code caching tags, and C ABI), tend to introduce the same pragmatic questions that will already need to be considered in choosing between the 3.10 and 4.0 alternatives. It's not just the version numbering aesthetics that need to be considered either - in addition to the point you raise around how the Python version gets embedded in file path names (such that the 3-digit form is technically ambiguous without a separator, and may break parsers that are expecting exactly two digits), there are other backwards compatibility concerns around how folks do version compatibility checks based on sys.version and sys.version_info. Python and CPython will be more than 3 decades old by 2022, and an ecosystem can build up a *lot* of implicit assumptions regarding how a platform's versioning scheme works in that kind of time frame :) Personally, I doubt we'll make a firm decision on how we're going to handle this until some time after 2.7 goes EOL in 2020, as by then we'll necessarily have a better idea of how the various Linux distros (including the LTS commercial ones) ended up handling the Python 2 -> Python 3 switch, and the fact that the next release at that point will be 3.9 making it eminently clear that we've run out of time to continue postponing the question. We'll hopefully also have more experience with folks relying on the stable runtime ABI, and hence whether or not it might be beneficial to define new "py4" and "abi4" compatibility tags for the binary wheel distribution format. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/