A blog from Nick Coghlan 
http://www.curiousefficiency.org/posts/2014/08/python-4000.html that 
should help put a few minds to rest.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

On 2014-08-17, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> A blog from Nick Coghlan 
> http://www.curiousefficiency.org/posts/2014/08/python-4000.html that 
> should help put a few minds to rest.

I agree with the comments that the appellation for "simply the next
version after 3.9" should be 3.10 and not 4.0.  Everybody I know
considers SW versions numbers to be dot-separated tuples, not 
floating point numbers.  

To all of us out here in user-land a change in the first value in the
version tuple means breakage and incompatibilities. And when the
second value is "0", you avoid it until some other sucker has found
the bugs and a few more minor releases have come out.

I don't think one (or several) blog posts is going to change the
perceptions and expectations that have been coditioned into us by
decades of experience with x.0 versions of countless software
packages. If it's just another in a a series of incremental "bug fix
and minor enhancements without breaking backwards incompatibility"
releases, you simply do not call it vers x.0.

-- 
Grant Edwards               grant.b.edwards        Yow! Bo Derek ruined
                                  at               my life!
                              gmail.com            

On Tue, Aug 19, 2014 at 12:51 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> I agree with the comments that the appellation for "simply the next
> version after 3.9" should be 3.10 and not 4.0.  Everybody I know
> considers SW versions numbers to be dot-separated tuples, not
> floating point numbers.
>

Agreed. However, by the time 3.9 comes out, there'll have been all
those years of changes. "The version after 3.9" would be a good time
to remove stuff that's been deprecated since 3.3 or 3.6 or whatever;
technically, that's breaking backward compat (hence 4.0 rather than
3.10), but in effect, it's no more breakage than a minor release would
give you (since you should have stopped using deprecated APIs several
versions ago). So there's still value in going to 4.0 around about ten
versions after 3.0; but it doesn't necessarily have to happen exactly
then.

ChrisA

"Grant Edwards" <invalid@invalid.invalid> wrote:

> To all of us out here in user-land a change in the first value in the
> version tuple means breakage and incompatibilities. And when the
> second value is "0", you avoid it until some other sucker has found
> the bugs and a few more minor releases have come out.

"Three shall be the number thou shalt count, and the number of the 
counting shall be three, no more, no less. .."
  https://www.youtube.com/watch?v=xOrgLj9lOwk   (1:30)

Or lets make the version asymptotically grow towards 4.
Any sensible function for that?

--gv

On 08/18/2014 07:51 AM, Grant Edwards wrote:
>
> To all of us out here in user-land a change in the first value in the
> version tuple means breakage and incompatibilities. And when the
> second value is "0", you avoid it until some other sucker has found
> the bugs and a few more minor releases have come out.

Even our own 3.0 was like that.


> I don't think one (or several) blog posts is going to change the
> perceptions and expectations that have been coditioned into us by
> decades of experience with x.0 versions of countless software
> packages. If it's just another in a a series of incremental "bug fix
> and minor enhancements without breaking backwards incompatibility"
> releases, you simply do not call it vers x.0.

Yup.

--
~Ethan~

On 08/18/2014 10:00 AM, ElChino wrote:
> "Grant Edwards" <invalid@invalid.invalid> wrote:
>
>> To all of us out here in user-land a change in the first value in the
>> version tuple means breakage and incompatibilities. And when the
>> second value is "0", you avoid it until some other sucker has found
>> the bugs and a few more minor releases have come out.
>
> "Three shall be the number thou shalt count, and the number of the counting shall be three, no more, no less. .."
>   https://www.youtube.com/watch?v=xOrgLj9lOwk   (1:30)

Right.  5.0 it is, then.

--
~Ethan~

On 2014-08-18, Ethan Furman <ethan@stoneleaf.us> wrote:
> On 08/18/2014 07:51 AM, Grant Edwards wrote:
>>
>> To all of us out here in user-land a change in the first value in the
>> version tuple means breakage and incompatibilities. And when the
>> second value is "0", you avoid it until some other sucker has found
>> the bugs and a few more minor releases have come out.
>
> Even our own 3.0 was like that.

So was 2.0, only it wasn't quite as distruptive as 3.0.

Don't get me started on the RedHat [5678].0 OS releases from back in
the day...

-- 
Grant 

On 8/18/2014 2:09 PM, Grant Edwards wrote:
> On 2014-08-18, Ethan Furman <ethan@stoneleaf.us> wrote:
>> On 08/18/2014 07:51 AM, Grant Edwards wrote:
>>>
>>> To all of us out here in user-land a change in the first value in the
>>> version tuple means breakage and incompatibilities. And when the
>>> second value is "0", you avoid it until some other sucker has found
>>> the bugs and a few more minor releases have come out.
>>
>> Even our own 3.0 was like that.
>
> So was 2.0, only it wasn't quite as distruptive as 3.0.

As I recall, 2.0 _was_ 1.6.

Emile

Grant Edwards <invalid@invalid.invalid> writes:

> I agree with the comments that the appellation for "simply the next
> version after 3.9" should be 3.10 and not 4.0. Everybody I know
> considers SW versions numbers to be dot-separated tuples, not floating
> point numbers.

This consensus is sometimes termed “semantic versioning”, that is,
giving semantic meaning to the structural elements of a version string
<URL:http://semver.org/>.

I'm glad someone has taken the time to codify that sensible and useful
de-facto standard for version strings.

> I don't think one (or several) blog posts is going to change the
> perceptions and expectations that have been coditioned into us by
> decades of experience with x.0 versions of countless software
> packages. If it's just another in a a series of incremental "bug fix
> and minor enhancements without breaking backwards incompatibility"
> releases, you simply do not call it vers x.0.

Agreed. The convention is well established and rogues deviate from it at
the peril of unnecessary confusion.

-- 
 \     “Guaranteed to work throughout its useful life.” —packaging for |
  `\                                          clockwork toy, Hong Kong |
_o__)                                                                  |
Ben Finney

On Tue, Aug 19, 2014 at 3:00 AM, ElChino <elchino@cnn.cn> wrote:
> Or lets make the version asymptotically grow towards 4.
> Any sensible function for that?

Easy! We just keep on adding parts.

3.7, 3.8, 3.9, 3.9.9, 3.9.9.9, 3.9.9.9.9, 3.9.9.9.9.9...

ChrisA

On Tue, Aug 19, 2014 at 10:05 AM, Steven D'Aprano
<steve+comp.lang.python@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

--001a11c1c2de6e20940500f0d65a
Content-Type: text/plain; charset=UTF-8

On 19 August 2014 00:51, Grant Edwards <invalid@invalid.invalid> wrote:

> On 2014-08-17, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> > A blog from Nick Coghlan
> > http://www.curiousefficiency.org/posts/2014/08/python-4000.html that
> > should help put a few minds to rest.
>
> I agree with the comments that the appellation for "simply the next
> version after 3.9" should be 3.10 and not 4.0.  Everybody I know
> considers SW versions numbers to be dot-separated tuples, not
> floating point numbers.
>
> To all of us out here in user-land a change in the first value in the
> version tuple means breakage and incompatibilities. And when the
> second value is "0", you avoid it until some other sucker has found
> the bugs and a few more minor releases have come out.
>

 No. A major version increase *may* introduce breakage and
incompatibilities. It does not mean that it *has* to introduce breakage and
incompatibilities. If the major version increase is documented as "just
being the next version" then there's no reason to avoid it - unless your
policy is "wait for the first patch release" i.e. never take major.minor.0
but always wait for major.minor.1.

What is more important is that minor and patch version increases should
avoid introducing breakage and incompatibilities wherever possible
(security fixes are one reason to allow incompatibility in a minor release).

BTW I agree with the idea that 4.0 would be an appropriate time to remove
anything that has been deprecated for the requisite number of versions.

Tim Delaney

--001a11c1c2de6e20940500f0d65a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
9 August 2014 00:51, Grant Edwards <span dir=3D"ltr">&lt;<a href=3D"mailto:=
invalid@invalid.invalid" target=3D"_blank">invalid@invalid.invalid</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"">On 2014-08-17, Mark Lawrence &lt;<a href=
=3D"mailto:breamoreboy@yahoo.co.uk">breamoreboy@yahoo.co.uk</a>&gt; wrote:<=
br>

&gt; A blog from Nick Coghlan<br>
&gt; <a href=3D"http://www.curiousefficiency.org/posts/2014/08/python-4000.=
html" target=3D"_blank">http://www.curiousefficiency.org/posts/2014/08/pyth=
on-4000.html</a> that<br>
&gt; should help put a few minds to rest.<br>
<br>
</div>I agree with the comments that the appellation for &quot;simply the n=
ext<br>
version after 3.9&quot; should be 3.10 and not 4.0.=C2=A0 Everybody I know<=
br>
considers SW versions numbers to be dot-separated tuples, not<br>
floating point numbers.<br>
<br>
To all of us out here in user-land a change in the first value in the<br>
version tuple means breakage and incompatibilities. And when the<br>
second value is &quot;0&quot;, you avoid it until some other sucker has fou=
nd<br>
the bugs and a few more minor releases have come out.<br></blockquote><div>=
<br></div><div>=C2=A0No. A major version increase *may* introduce breakage =
and incompatibilities. It does not mean that it *has* to introduce breakage=
 and incompatibilities. If the major version increase is documented as &quo=
t;just being the next version&quot; then there&#39;s no reason to avoid it =
- unless your policy is &quot;wait for the first patch release&quot; i.e. n=
ever take major.minor.0 but always wait for major.minor.1.</div>
<div><br></div><div>What is more important is that minor and patch version =
increases should avoid introducing breakage and incompatibilities wherever =
possible (security fixes are one reason to allow incompatibility in a minor=
 release).</div>
<div><br></div><div>BTW I agree with the idea that 4.0 would be an appropri=
ate time to remove anything that has been deprecated for the requisite numb=
er of versions.<br></div><div><br></div><div>Tim Delaney</div></div></div>
</div>

--001a11c1c2de6e20940500f0d65a--

Ben Finney wrote:

> Grant Edwards <invalid@invalid.invalid> writes:
> 
>> I agree with the comments that the appellation for "simply the next
>> version after 3.9" should be 3.10 and not 4.0. Everybody I know
>> considers SW versions numbers to be dot-separated tuples, not floating
>> point numbers.
> 
> This consensus is sometimes termed “semantic versioning”, that is,
> giving semantic meaning to the structural elements of a version string
> <URL:http://semver.org/>.
> 
> I'm glad someone has taken the time to codify that sensible and useful
> de-facto standard for version strings.
> 
>> I don't think one (or several) blog posts is going to change the
>> perceptions and expectations that have been coditioned into us by
>> decades of experience with x.0 versions of countless software
>> packages. If it's just another in a a series of incremental "bug fix
>> and minor enhancements without breaking backwards incompatibility"
>> releases, you simply do not call it vers x.0.
> 
> Agreed. The convention is well established 

Only if you ignore the vast majority of software which does not follow that
convention. Having *any* semantics to version numbers at all, apart
from "bump the version number when you feel like it", is the exception
rather than the rule. Probably the most common version numbering system
is "the date I last remembered to update the version number", or a simple
incrementing counter. (It's a version *number*, not a version tuple.)

It is amazing how well-established a convention can appear if you ignore the
exceptions to it and consider only a sufficiently narrow niche, like "some
of the FOSS software I'm familiar with".


> and rogues deviate from it at the peril of unnecessary confusion.

Rogues like Python, the Linux kernel, Oracle, Mozilla, Haskell, ...

Well, okay, Oracle are rogues. But not because of their version numbering.


I find it amusing that Haskell uses a versioning number scheme that uses two
dot-separated major versions specifically to combat the emotional reaction
to major-version changes exhibited in this thread by Grant. With Haskell,
changing from (say) 0.6.3.2 -> 0.7.0.0 is a major API-breaking upgrade, but
it avoids the emotional reaction of having to go from 6.3.2 -> 7.0.0.

http://www.haskell.org/haskellwiki/Package_versioning_policy

Haskell also explicitly prohibits the useful practice of including version
tags like "a", "b", "rc" *because some tools couldn't sort them correctly*.
(This reminds me of those who advocate spaces over tabs, because some tools
can't deal with tabs correctly.) Rather than fix the tools, the Haskell
community removed non-numeric tags from the specification.

On the other hand, Oracle and Sun before them take the attitude that a jump
in Java's version number from 5 to 6 to 7 are only minor release changes,
and the Java community is quite happy to agree.



-- 
Steven

Grant Edwards wrote:

> On 2014-08-17, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> A blog from Nick Coghlan
>> http://www.curiousefficiency.org/posts/2014/08/python-4000.html that
>> should help put a few minds to rest.
> 
> I agree with the comments that the appellation for "simply the next
> version after 3.9" should be 3.10 and not 4.0.  Everybody I know
> considers SW versions numbers to be dot-separated tuples, not
> floating point numbers.

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.

 
> To all of us out here in user-land a change in the first value in the
> version tuple means breakage and incompatibilities.

*All* of us?

So... you're not a user of the Linux kernel?

http://www.linuxplanet.com/news/goodbye-linux-2.6-hello-linux-3.0.html

Or Java 5, 6, 7, 8.

http://en.wikipedia.org/wiki/Java_version_history

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.)

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.

Or for that matter, not a Python user either:

https://docs.python.org/dev/whatsnew/2.0.html

Version 4.0, when it comes out, will merely be a return to past practices in
Python-land, which are quite similar to practices in many major software
packages. Version 3.0 was the anomaly.



-- 
Steven

Grant Edwards wrote:

> On 2014-08-18, Ethan Furman <ethan@stoneleaf.us> wrote:
>> On 08/18/2014 07:51 AM, Grant Edwards wrote:
>>>
>>> To all of us out here in user-land a change in the first value in the
>>> version tuple means breakage and incompatibilities. And when the
>>> second value is "0", you avoid it until some other sucker has found
>>> the bugs and a few more minor releases have come out.
>>
>> Even our own 3.0 was like that.
> 
> So was 2.0, only it wasn't quite as distruptive as 3.0.

How was it disruptive? It was as backward compatible to 1.5 as any point
release can be expected to be. There were syntax changes, but they added
new syntax, and didn't take anything away.

In my opinion, 2.6 was a bigger change than 2.0 from the perspective of
backwards compatibility. 2.6 finally made raising from strings an error.

# 2.4
py> raise "hello"
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
hello

# 2.6
py> raise "hello"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: exceptions must be old-style classes or derived from
BaseException, not str

(I make no comment about the quality of 2.0 versus 2.0.1 :-)



-- 
Steven

On 2014-08-19, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> Grant Edwards wrote:
>
>> On 2014-08-18, Ethan Furman <ethan@stoneleaf.us> wrote:
>>> On 08/18/2014 07:51 AM, Grant Edwards wrote:
>>>>
>>>> To all of us out here in user-land a change in the first value in the
>>>> version tuple means breakage and incompatibilities. And when the
>>>> second value is "0", you avoid it until some other sucker has found
>>>> the bugs and a few more minor releases have come out.
>>>
>>> Even our own 3.0 was like that.
>> 
>> So was 2.0, only it wasn't quite as distruptive as 3.0.
>
> How was it disruptive? It was as backward compatible to 1.5 as any point
> release can be expected to be. There were syntax changes, but they added
> new syntax, and didn't take anything away.
>
> In my opinion, 2.6 was a bigger change than 2.0 from the perspective of
> backwards compatibility. 2.6 finally made raising from strings an error.

I'm probably conflating the 1.5.2/2.0 and the 2.6 stuff.  I do
remember delaying moving from 1.5.2 -> 2.0 until I really had to, but 
I don't remember why.

-- 
Grant Edwards               grant.b.edwards        Yow! Oh, I get it!!
                                  at               "The BEACH goes on", huh,
                              gmail.com            SONNY??

On Tue, Aug 19, 2014 at 9:27 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> I'm probably conflating the 1.5.2/2.0 and the 2.6 stuff.  I do
> remember delaying moving from 1.5.2 -> 2.0 until I really had to, but
> I don't remember why.

If you were a RedHat user during that timeframe, that might have
contributed to your decision to delay. I no longer remember the
details, but it was rather painful.

Skip

P.S. Grant, why is your email listed as invalid@invalid.invalid? Seems
kind of unfriendly.

On 2014-08-19, Skip Montanaro <skip@pobox.com> wrote:
> On Tue, Aug 19, 2014 at 9:27 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>> I'm probably conflating the 1.5.2/2.0 and the 2.6 stuff.  I do
>> remember delaying moving from 1.5.2 -> 2.0 until I really had to, but
>> I don't remember why.
>
> If you were a RedHat user during that timeframe, that might have
> contributed to your decision to delay. I no longer remember the
> details, but it was rather painful.
>
> Skip
>
> P.S. Grant, why is your email listed as invalid@invalid.invalid? Seems
>      kind of unfriendly.

Many, many years ago it was an attept to reduce spam and to avoid
receiving copies of followups.  There used to be a fair number of
Usenet and mailing-list users who seemed to think that their followups
were so important that they would not only post it to the group (or
mail it to the mailing list), they would also send you a copy
directly.  I got tired of messing with procmail filters to try to
eliminate those, so I finally removed my e-mail address from the
headers.  If people want to e-mail me, my address is below.

-- 
Grant Edwards               grant.b.edwards        Yow! Vote for ME -- I'm
                                  at               well-tapered, half-cocked,
                              gmail.com            ill-conceived and
                                                   TAX-DEFERRED!

Skip Montanaro <skip@pobox.com> writes:

> On Tue, Aug 19, 2014 at 9:27 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>> I'm probably conflating the 1.5.2/2.0 and the 2.6 stuff.  I do
>> remember delaying moving from 1.5.2 -> 2.0 until I really had to, but
>> I don't remember why.
>
> If you were a RedHat user during that timeframe, that might have
> contributed to your decision to delay. I no longer remember the
> details, but it was rather painful.

I vaguely remember holding off for a while until SWIG had 2.0 support,
or maybe Numeric lagged, or something, but that's getting pretty fuzzy.
There was definitely more there than, say, for 1.4 to 1.5.  It's hard to
believe that the Dubois/Hinsen/Hugunin article in Computers in Physics
(which was where I got my start with python) was a full 18 years ago.

Cheers,
Johann

Grant Edwards wrote:

> I do
> remember delaying moving from 1.5.2 -> 2.0 until I really had to, but
> I don't remember why.

I remember delaying moving from 1.5 until 2.3, but I remember why. Three
reasons:

(1) People are often like cats, and like cats, they are either curious and
inquisitive about anything new ("ooh, shiny! is it good to play with???")
or suspicious and fearful of anything new ("it's different, I don't like
it"). I happened to be going through a stage of my life closer to the
second than the first at the time.

(2) I was reluctant to install software by hand if it wasn't handled by my
system's package manager. I still am, but not as reluctant as I was back
then.

(3) I was still learning the language, and all the books I had on Python
covered 1.5.


-- 
Steven

Le dimanche 17 ao=FBt 2014 14:37:02 UTC+2, Mark Lawrence a =E9crit=A0:
> A blog from Nick Coghlan=20
>=20

At least one py dev, who has a correct understanding
and vision of what is Unicode or as it is supposed to
be.

My position: I'm on the side of the TeX unicode
engines and luckily it does match the platform
I'm using.

jmf