On Tue, Feb 2, 2016 at 4:54 PM, R. David Murray firstname.lastname@example.org wrote:
On Tue, 02 Feb 2016 15:33:58 +0200, Ezio Melotti email@example.com wrote:
On Sat, Jan 30, 2016 at 5:36 AM, Guido van Rossum firstname.lastname@example.org wrote:
Following the lead of 2.7.10 and 2.7.11 we could continue with 3.10, 3.11, etc.
I think we should continue with 3.10, 3.11, etc. Changing the major version should be done for incompatible changes, and just doing it after 3.9 will probably just create confusion for both users that will wonder if it's incompatible with Python 3 and for things like the executable name. Hopefully we won't need to jump to Python 4 for a long time.
I also want the 3->4 transition to feel like a non-event for most users. How we'll do that I don't know yet, but I want it to be a lot smoother than 2->3.
I think Guido's point is that we shouldn't *make* incompatible changes, and that the 4.0 transition should be smooth so that people learn we are committed to that. This is potentially analogous to the linux transition from 2.x to 3.x, despite the fact that it goes against the rules of semantic versioning.
That said, I don't view removing deprecated things as a incompatible change, since code that has dealt with the deprecations will run on both the version before (usually versions plural) and the version after the removal. Whether we should do a mass removal in 4.0 (or the first post 2.7 release) is a question, and so far the sense I get of the community is that there is not even close to a consensus on that. But it would give a semantic versioning meaning to the change from 3.x to 4.x, without actually being all that disruptive. On the other hand, a mass removal would be more disruption than removals spaced over several releases, so FUD might well arise as an issue, as you say.
There are two main types of changes that can make a new release incompatible with the previous:
builtins, nested scopes, absolute imports, unicode strings by default, and adding new keywords);
For the former, we do it regularly in minor releases. For the latter the situation is more complicated. We did most of those in 3.0, but we changed semantics with nested scopes in 2.2  and introduced new keywords like "yield" and "with" in 2.3  and 2.6  (using __future__ imports) first. I believe that all these things can be done in a minor release, and could have been done for Python 3.0 too, but it would have been really difficult considering the magnitude of some of the changes.
Some amount of breakage happens with any new release, but we can choose two different approaches:
If we choose the former, we might never need to bump the major release to 4.0. If we choose the latter (like we did for Python 3) we will have an incompatible Python 4 (even though the incompatibilities might be minor). There's also a third option of bumping to 4.0 once some major (but backward compatible) change is done, such as removing the GIL or adding a JIT (or both). I'm not sure making a mass-removal of deprecated APIs for 4.0 makes too much sense, especially if we want to minimize breakage.
Also note that by choosing the first option we might increase the chances that a program written for 3.6 won't run on e.g. 3.9, thus forcing developers to keep up with the changes that each minor release introduces. Providing 3to3 fixers might make the transition easier.
What we decide will likely affect the deprecation policy we want to follow.
Best Regards, Ezio Melotti
Regardless though, the name is an issue :)
So, I guess I see the arguments between going 3.9->4.0 vs 3.9->3.10 as fairly balanced and don't have a strong preference.
--David _______________________________________________ python-committers mailing list email@example.com https://mail.python.org/mailman/listinfo/python-committers