[Python-ideas] Proposal to change Python version release cycle
mal at egenix.com
Sat Nov 4 11:44:08 EDT 2017
Just to clarify: Python 2.0 was called 2.0 because the BeOpen marketing
department thought it was good idea, not because there were major
incompatible changes going into that release.
Porting code from Python 1.5.2 to 2.0 was relatively straight forward
and not much different from other minor releases.
The first ever major backwards incompatibility release switch we
had in Python after the great renaming of the C APIs between
Python 1.1 and 1.2 (which was only visible to C extensions and
relatively easy to fix using a compatibility header file),
was the transition from Python 2.x to Python 3.x.
IMO, the only reason to do this again would be the removal of
the GIL, but only if there's absolutely no other way to get
around such breakage.
I would very much appreciate Python's releases not to introduce
such major changes anymore. A continuous gradual change is a lot
better to handle than non-continuous breaks and I'm pretty
sure both will get us to the same level functionality eventually,
perhaps even avoiding a few new mistakes along the way.
With that approach, the versioning scheme would just be an
implementation detail, which is good. Whether we call it Python
4.2 or Python 42 is really not all that important. Python
is mature enough to not have to pull marketing tricks anymore.
Professional Python Services directly from the Experts (#1, Nov 04 2017)
>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/
>>> Python Database Interfaces ... http://products.egenix.com/
>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
More information about the Python-ideas