Why Python 4.0 won't be like Python 3.0

Chris Angelico rosuav at gmail.com
Mon Aug 18 20:30:20 EDT 2014


On Tue, Aug 19, 2014 at 10:05 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> I consider versions to be *strings*. They include non-numeric components
> such as "a", "b", "rc", so they aren't numbers. They're certainly not
> floating point numbers, since they have a variable number of decimal
> points. Although there is at least one unofficial standard for interpreting
> version numbers (semantic versioning), the most popular by far is "whatever
> I mean by it today" and the only reasonable interpretation of an arbitrary
> software package's version "number" is as free-form text.
>
> Given two version numbers for the same arbitrary package, X and Y, just
> about the only thing you can be sure of is that if X < Y, Y is *probably*
> newer.

Let's say "version identifiers". The point of schemes like semver.org
is to make it possible to define the "X < Y" inequality between two
such identifiers. (There are similar schemes, such as that used by
Debian's package management. They're often broadly compatible.)

> Or Java 5, 6, 7, 8.
>
> http://en.wikipedia.org/wiki/Java_version_history

Are they major versions, or 1.5, 1.6, 1.7, 1.8? Or both?

> Or Firefox.
>
> https://support.mozilla.org/en-US/questions/956361
>
> (I believe that Firefox is now up to version 31, with version 32 due at
> 3:00pm and 33 due at 5:30pm.)

So true.

> And not a Mac user either, I imagine, since Mac OS introduces major backward
> incompatible changes to point releases. Mac OS version X tends to prefer
> version *names* rather than numbers:
>
> http://en.wikipedia.org/wiki/History_of_OS_X
>
> which Debian-based Linux distros also tend to follow.

With Debian distros, there is a version number as well as the name -
Wheezy (current stable) is Debian 7, currently showing 7.5, and the
previous version (Squeeze) is Debian 6. This more-or-less follows the
standard concept of major versions, as it's at the point of a new
release that breaking changes will be made.

There's a broad expectation in a lot of communities that the basic
"major.minor.rev" scheme will be followed. It's definitely not
universal, but it's the most popular convention by far (unless you
count "version numbers don't mean anything" as a convention).

ChrisA



More information about the Python-list mailing list