On Tue, Feb 02, 2016 at 09:40:52AM -0500, Barry Warsaw wrote:
On Feb 02, 2016, at 03:33 PM, Ezio Melotti wrote:
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.
Changing the major version number is a much bigger political and psychological step than just bumping 3 to 4. I say let's put it off as long as possible, and there's nothing wrong with two digit minor versions.
It will break any code that does
if sys.version < "3.3": ...
for example. Sure, people shouldn't do that, but they will.
Are there any other languages or systems which bumped the major version number while keeping language changes relatively minor? I can think of a couple of examples of languages which bumped the major version number without making big disruptive changes:
- Python 1.5 -> 2.0 (technically there was a 1.6 in there as well, but that wasn't used by many people).
Admittedly, fewer people used Python back then, and the version bump wasn't following a similiar, but backwards incompatible, version bump.
PHP 5.x -> 7.0. I count nine feature removals, but none of them look big. http://php.net/ChangeLog-7.php
Java major version bumps are rarely backwards incompatible, as far as I can tell. I had a Java developer explain to me that he treats the N in "Java N" as effectively a minor release number.
The point being, I'm not entirely sure I agree that a major version bump would *necessarily* be considered a big deal, let alone a barrier to adoption. It might be nice to have a really big feature added in 4.0 to justify the version bump, but I don't think it's a "Must Do". Having 4.0 being a lightweight evolutionary step up from 3.9 might even reassure people that we're back to normal operating practice, without the extraordinary 2->3 transition.
-- Steve