[Python-Dev] Python 4: don't remove anything, don't break backward compatibility (original) (raw)
Steven D'Aprano steve at pearwood.info
Mon Mar 10 16:04:52 CET 2014
- Previous message: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility
- Next message: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, Mar 10, 2014 at 02:55:26PM +0100, Victor Stinner wrote: [...]
So can we please try to stop scheduling another major Python version breaking almost all modules and all applications just to be pendantic?
No, we should not remove any old feature in Python 4. Python 4 should be just a minor release following the previous 3.x release.
I often talk about "Python 4000" as the next possible opportunity for major backwards incompatible changes, but of course that's not decided yet, and given the long term pain of the 2->3 transition, it may be quite conservative, with no radical changes. Perhaps I ought to use Python 5000 as my target for radical language changes?
For example, I propose to release the next major Python version (3.5) with the version 4.0 but without removing anything. (It's just an example, it can wait another release.)
If Python 4 is a conservative release, I don't see any reason to bump the major version number until after Python 3.9. So, assuming no further radical changes to the language like 2->3, we'd have five more point releases before needing to deal with 4.0.
Perhaps we need a long-term schedule?
3.5: August 2015 3.6: February 2017 3.7: August 2018 3.8: February 2020 3.9: August 2021 4.0: February 2023
give or take a few months.
-- Steven
- Previous message: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility
- Next message: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]