Python milestone releases

[Thomas D'Tak]

Hi everybody!

Recently, I am having more and more problems with the fact that
my Python version is far ahead of the Python versions I have to
write scripts for (CGI servers, LAN servers & clients etc. of
customers, ISPs etc.). Sometimes, these Python versions reach
back to Python 2.0.

The question is now, how to handle this kind of problems?

I do not want to complain here that Python is developing too
fast; and I do not want to criticize Python's system of version
numbers. But I want to ask for resp. suggest something like
*official Python milestone releases*. (Please correct me if
something like that does already exist and I am just not aware
of it.)

Official Python milestone release statements should discourage
the use of older versions. Moreover, not each and every Python
release should be a milestone release (clearly).

Having milestone releases would make it easier to suggest to
customers, ISPs etc. to install a new Python version (the mile-
stone). Having milestones would put some pressure on them. (Well,
that sounds quite negative: 'pressure'; but I think you know what
I mean. Often, a server gets installed once and sees nothing
else but security updates after that; getting a new version of
a software package on such a server can be quite hard if you are
not the admin resp. are not allowed to install your own version
of the software package.)

Another solution would be to stick to Python 2.0 forever -where
'forever' means the time span until the release of Python 3.0-
(but I really do not like that idea

Having milestones (not too often) would also simplify a lot of
other things; e.g. I would not have to study 'What's new in Python ...'
each and every time I have to write scripts for an older version
of Python. The 'older' version would simply be the last milestone
and I would have to know about two Python versions only: the milestone
and the most recent one.

How do you handle the above kind of problems resp. what do you think
about *official* Python milestones?

Thanks in advance for your answers! Th.

 

[Anthony Baxter]

I do not want to complain here that Python is developing too
fast; and I do not want to criticize Python's system of version
numbers. But I want to ask for resp. suggest something like
*official Python milestone releases*. (Please correct me if
something like that does already exist and I am just not aware
of it.)

Official Python milestone release statements should discourage
the use of older versions. Moreover, not each and every Python
release should be a milestone release (clearly).

How exactly would this be different to our existing release process?
In case it's not clear, the webpages for old versions of Python already
state "This version is old, and you should use a newer version". Most
bugfix releases, I try to put words in to encourage people to upgrade.

I'm not sure how "2.3" isn't a milestone in any way that's meaningful.

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

The question is now, how to handle this kind of problems?

The Python Business Forum once tried to attack the problem
by planning to release a "Python-in-a-tie" release. This
release would be maintained essentially forever, and they
wanted PythonLabs to commit that this release is not
superceded by another release for atleast a year. Python
2.2 was chosen as the basis, and indeed, it lived for 18
months without a successor. Today, 2.2 is not maintained
anymore by the "usual" maintainers, which have moved towards
2.3 and 2.4. Nobody has taken over maintenance of 2.2,
from which I conclude there is really no need for ongoing
maintenance of old releases.

Now, if your partners are still running Python versions
too old for your software, the pressure to upgrade should
come from you, the one who needs the newer version. Python
supports side-by-side installation of multiple versions,
so this should cause no problem (except for the disk space,
of course).

Regards,
Martin

 

[Anthony Baxter]

The Python Business Forum once tried to attack the problem
by planning to release a "Python-in-a-tie" release. This
release would be maintained essentially forever, and they
wanted PythonLabs to commit that this release is not
superceded by another release for atleast a year. Python
2.2 was chosen as the basis, and indeed, it lived for 18
months without a successor. Today, 2.2 is not maintained
anymore by the "usual" maintainers, which have moved towards
2.3 and 2.4. Nobody has taken over maintenance of 2.2,
from which I conclude there is really no need for ongoing
maintenance of old releases.

My approach is that I'm happy to manage releases like so:

Python 2.x
Python 2.x.1
Python 2.x.2
.....
Python 2.(x+1)
Python 2.x.n -- one last release of the old branch
Python 2.(x+1).1
.....

That is, only one branch "under maintenance" at a time. I thought
about maintaining 2.2 for longer, but really could see no reason to
do so. It increases the workload of committers, who now might have
to backport to two separate branches as well as the trunk.

Having said that, if someone else wants to step forward and continue
to maintain 2.3 past 2.3.5 (which is the last release of 2.3 I plan to do),
they're more than welcome to do so.

 

[David Fraser]

The Python Business Forum once tried to attack the problem
by planning to release a "Python-in-a-tie" release. This
release would be maintained essentially forever, and they
wanted PythonLabs to commit that this release is not
superceded by another release for atleast a year. Python
2.2 was chosen as the basis, and indeed, it lived for 18
months without a successor. Today, 2.2 is not maintained
anymore by the "usual" maintainers, which have moved towards
2.3 and 2.4. Nobody has taken over maintenance of 2.2,
from which I conclude there is really no need for ongoing
maintenance of old releases.

Now, if your partners are still running Python versions
too old for your software, the pressure to upgrade should
come from you, the one who needs the newer version. Python
supports side-by-side installation of multiple versions,
so this should cause no problem (except for the disk space,
of course).

Regards,
Martin

What may be easier in some situations is to have back-ported versions of
new standard modules that will run with previous versions of Python.
For example, Python 2.3 introduces the datetime module ; to require
people to upgrade from Python 2.2 for a new module seems steep ...

David

 

[Anthony Baxter]

What may be easier in some situations is to have back-ported versions of
new standard modules that will run with previous versions of Python.
For example, Python 2.3 introduces the datetime module ; to require
people to upgrade from Python 2.2 for a new module seems steep ...

That happens sometimes - for instance, spambayes includes a version
of the sets.py module for Python 2.2. But in general it's probably not
going to happen unless someone steps forward to do it - there's very
little advantage to me, for instance, in doing this, as I don't run 2.2 on
anything. (2.3 was such a painless upgrade from 2.2 that I don't have
a problem doing this).

Note, though, that there is a pure-python version of the datetime module
(it was the original version) so you're probably in luck. Assuming, of course,
that it doesn't use any 2.3-isms.

 

[Tom B.]

Hi everybody!

Recently, I am having more and more problems with the fact that
my Python version is far ahead of the Python versions I have to
write scripts for (CGI servers, LAN servers & clients etc. of
customers, ISPs etc.). Sometimes, these Python versions reach
back to Python 2.0.

The question is now, how to handle this kind of problems?

I do not want to complain here that Python is developing too
fast; and I do not want to criticize Python's system of version
numbers. But I want to ask for resp. suggest something like
*official Python milestone releases*. (Please correct me if
something like that does already exist and I am just not aware
of it.)

Anythin thats not a Beta is an *official Python milestone release*,

Tom

 

[Thomas D'Tak]

I'm not sure how "2.3" isn't a milestone in any way that's meaningful.

For programmers, I agree.

But for other people (server admins etc.), I think, the following
would be important:

- First of all, it should be mentioned somewhere (in a prominent place,
such that even first-time visitors of python.org can find it easily).

- Not every release should be a milestone release;
milestones should not come more often than maybe every 2 years.
(E.g. 2.0 and 2.3 would have been good candidates IMO.)

And -even for programmers- the following could be important:

- Some kind of support would be needed for the milestone releases,
even after the release of other -non-milestone- Python versions;
(e.g. bug fixes, backports of important new packages).


Martin v. Löwis describes in his follow-up to my original posting, that
some of the above did hold for Python 2.2. (But, actually, I was not aware
of that.)

Th.

 

[Anthony Baxter]

- First of all, it should be mentioned somewhere (in a prominent place,
such that even first-time visitors of python.org can find it easily).

So we'd have some major releases that are more major than others?
Pass.

- Not every release should be a milestone release;
milestones should not come more often than maybe every 2 years.
(E.g. 2.0 and 2.3 would have been good candidates IMO.)

See, I'd have said 2.1 and 2.3. 2.1 was the last release before the
new objects went in. Note also that major releases are typically
12-18 months apart. Python 2.1, for instance, is now over three
years old.

And -even for programmers- the following could be important:

- Some kind of support would be needed for the milestone releases,
even after the release of other -non-milestone- Python versions;
(e.g. bug fixes, backports of important new packages).

Volunteers to do this are more than welcome to do so, and I think that
the python dev community would be more than happy to do what's
needed to make this happen, if someone would offer to do it. I'm happy
to help someone who wants to do this, and is willing to commit to doing
this, to get up to speed. But please be aware that this is a non-trivial
amount of work.

I can say, that in my (current) role as release manager, I'm utterly
uninterested in doing this. One maintenance branch, with the
regular 6-monthly bugfix releases, is quite enough for me, thank
you.