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
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
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
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
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
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
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
to post comments)