Python gears up for 2.6 and 3.0 [LWN.net]

By Jake Edge
March 19, 2008

Things are heating up in the Python world in advance of two major synchronized releases of the language. As it heads towards Python 3000 (aka Py3k or Python 3.0), alongside the transitional version 2.6, the development team is narrowing its focus to just those items that are required for the releases. Along the way, the conversations taking place on python-devel provide a look inside the development and release process decisions that a project needs to make as releases loom.

Py3k is the next-generation version of Python, as we described last September. It will not be backward compatible with programs written for Python 2.x in a wide variety of ways. Python 2.6 is an effort to bridge the gap, enabling much of the 3.0 functionality so that new programs can start using it. It can also provide warnings for code that will not work with Py3k.

Python 2.6 was originally scheduled for an April 2008 release, in advance of the August 2008 release planned for Py3k. Now the two are slated for synchronized releases, roughly monthly, until the final release now scheduled for early September 2008. The synchronization is seen as important for two reasons as Python's Benevolent Dictator For Life (BDFL) Guido van Rossum outlines:

Not only could this potentially save the release manager and his assistants some time, doing the final releases together sends a clear signal to the community that both versions will receive equal support.

Because Py3k is such a radical change, the 2.x series will continue for a long time. van Rossum's recent PyCon keynote (PDF slides) mentions five years as the time frame for 2.6 to be supported, with 2.7 and 2.8 releases possible. A stable development platform for the next few years is very important for current Python users as is giving them a long time to migrate their code.

The third alpha of Py3k was released at the end of February along with the first alpha of 2.6. Additional alpha releases of each are slated for April and May as laid out in Python Enhancement Proposal (PEP) 361. Those are to be followed by betas in June and July with the final release planned for September 3. All of that adds up to a fairly aggressive schedule, but the team seems confident—at least so far.

One of the issues that the Python hackers are trying to figure out is how to track the items still left to be done. van Rossum describes the scope of the problem:

In order to make such a tight release schedule we should try to come up with a list of tasks that need to be done, and prioritize them. This should include documentation, and supporting tools like 2to3. It should include features, backports of features, cleanup, bugs, and whatever else needs to be done (e.g. bugbot maintenance).

No one had any major objections to van Rossum's suggestion of using the bug tracker to track the tasks, with Christian Heimes pointing out:

Despite the url bugs.python.org it's an issue tracker and not a bug tracker. We track patches, feature requests, ideas and bugs in the same tracker.

The bug tracker allows for different priorities to be set on bugs (or tasks) that are entered into it, which led van Rossum and others to wonder about the proper usage of that field. One of the problems is distinguishing between issues that must be addressed before the next release versus those that must be addressed sometime before the final release. In some sense, both are "critical" and "show-stopping" (depending on which show you are focused on). Brett Cannon reported the scheme they came up with:

So "release blocker" blocks a release. "Critical" could very easily block a release, but not the current one. "High" issues should be addressed, but won't block anything. "Normal" is normal. And "low" is for spelling errors and such.

This can elevate bugs that are relatively minor, but need to be handled before a final release, into a category that inflates their importance. But, not elevating the bugs can lead to them incorrectly being set aside for a later release. van Rossum wondered about this bug priority "inflation", but it is the way that 2.6/3.0 release manager Barry Warsaw wants to handle things:

Critical is the right one to use. Neal and I will basically be moving issues between 'release blocker' and 'critical' with the former meaning this issue blocks the upcoming release.

Other projects or project managers might make different decisions on how to handle bug priorities, but the important thing is to make a reasonable decision quickly. Once that was done, the tasks were added to the tracker and could be prioritized correctly within the framework and without a lot of hand-wringing about which way is "best". It is an important skill for project managers of all kinds to learn.

Things are progressing rapidly on python-devel these days—not surprising with two major releases due in less than six months. There is a lot of work to be done, but the Python hackers aren't shrinking from those tasks. In addition, the team has also been able to change their processes as needed to support their tight schedule. With hard work and a bit of luck that should put Py3k and its 2.6 sibling on our development machines by autumn.

(Log in to post comments)

Python gears up for 2.6 and 3.0

Posted Mar 24, 2008 19:06 UTC (Mon) by pboddie (subscriber, #50784) [Link]

No, Roundup is Free Software. They wanted to use a proprietary solution (offered gratis by the
developers of that solution), but were asked to reconsider for a number of reasons; these
included the obvious publicity, advocacy and technical benefits related to using a Python
solution which is also Free Software, especially one which is regarded to be mature enough to
do the job.

The Python community does try and make its technology appealing to conservative software
development types, but I think it is often easy to overlook the potential for negative
publicity if such people then see that the developers producing the technology do not
themselves use that technology to manage the project itself (so you'd get Slashdot headlines
like "Python bug tracker uses closed, non-Python solution" and a hundred wisecracks following
up on it). At the very least, if you're producing Free Software and attempting to get
conservative people to use it, you should also send the signal that Free Software is good
enough for you too.

Had the previously favoured Java-based solution been Free Software, perhaps it would have been
an uncontroversial choice, since one can always say that the benefits of open solutions are
more important than technological details. There's no need to rewrite everything in one's
favourite language if the existing solutions are usable enough, but the availability of
suitable Free Software solutions in Python made it more likely that one of those solutions
would eventually be chosen.