[Python-ideas] Proposal to change Python version release cycle
Wolfgang
tds333 at mailbox.org
Sat Nov 4 14:10:09 EDT 2017
On 04.11.2017 16:44, M.-A. Lemburg wrote:
> 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.
Thanks for the interesting details.
Have to admit I entered the Python land with version 1.4
and missed the C API change from 1.1 to 1.2 completely. :-)
Getting more opinions about the idea confirms me slowly
to something like, good to discuss but not worth the change.
Because some arguments confirmed me that it is not worth
to change this. Also the marketing argument is weak and you are right
that it should not care us.
The only remaining argument is to have shorter release cycles
but I think they don't depend on the versioning scheme nor
a change in it improves this.
Looking forward to 2020 when 2.7 is out of business and
the maintenance cost can be invested in Python 4 and a faster release
schedule.
:-)
Regards,
Wolfgang
More information about the Python-ideas
mailing list