Python pre-release announcements (was: Python 2.5.3: call for patches)

Ben Finney bignose+hates-spam at
Tue Oct 7 10:10:41 CEST 2008

"Martin v. Löwis" <martin at> writes:

> Within a few weeks, we will release Python 2.5.3.

I'm glad to see this. Thank you to all involved in the ongoing work of
coordinating Python releases.

Can I request, in the interest of reducing confusion, that any
announcements of pre-release versions of 2.5.3 (or any other Python
release) be announced *without* saying “RELEASED: A not-really-release
version of Python”.

It's very confusing to see a progression of announcements with subject
fields like:

    RELEASED: Python 2.8.not-ready-yet
    RELEASED: Python 2.8.alpha-1
    RELEASED: Python 2.8.beta-1
    RELEASED: Python 2.8.beta-2
    RELEASED: Python 2.8 release candidate 1
    RELEASED: Python 2.8 release candidate 2
    RELEASED: Python 2.8 final

The word “RELEASED” is a strong indicator that a new version of
Python (in this case) is *released*, not merely available in a
pre-release form. The only one that qualifies in the above list is the
last one where Python 2.8 is *actually* released. Otherwise, the word
becomes overburdened with too many meanings and doesn't indicate
anything strongly.

It would be much less confusing if the word “release” in such
announcements was reserved for the release *of that version* (in this
case, 2.8), and not for the availability of some pre-release. Perhaps
simply using the word “ANNOUNCED” or abbreviated “ANN”:

    [ANN] Python 2.8.not-ready-yet
    [ANN] Python 2.8.alpha-1
    [ANN] Python 2.8.beta-1
    [ANN] Python 2.8.beta-2
    [ANN] Python 2.8 release candidate 1
    [ANN] Python 2.8 release candidate 2
    [ANN] Python 2.8 final

That, to me at least, communicates what's actually happening far
better and leads to less confusion about what the state of release is.

I recall making this point some while ago to positive effect (thank
you!), but it seems to have been ignored in the recent progression of
announcements for Python 2.6. I didn't want to complain at that point,
with such a good job being done otherwise by the Python 2.6 release

Is there some policy document or release management guide that could
be updated for release teams to follow on this without needing to have
this discussion every time?

 \        “I used to work in a fire hydrant factory. You couldn't park |
  `\                          anywhere near the place.” —Steven Wright |
_o__)                                                                  |
Ben Finney

More information about the Python-list mailing list