RELEASED Python 2.5.2, release candidate 1

[Martin v. Löwis]

On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.5.2 (release candidate 1).

This is the second bugfix release of Python 2.5. Python 2.5 is now in
bugfix-only mode; no new features are being added. According to the
release notes, over 100 bugs and patches have been addressed since
Python 2.5.1, many of them improving the stability of the interpreter,
and improving its portability.

For more information on Python 2.5.2, including download links for
various platforms, release notes, and known issues, please see:

http://www.python.org/2.5.2/

Highlights of this new release include:

Bug fixes. According to the release notes, at least 100 have been fixed.

Highlights of the previous major Python release (2.5) are available
from the Python 2.5 page, at

http://www.python.org/2.5/highlights.html

Enjoy this release,
Martin

Martin v. Loewis
(e-mail address removed)
Python Release Manager
(on behalf of the entire python-dev team)

 

[hcs]

The Mac binary is giving a 404. When/if it's supposed to work, will it
upgrade the Leopard standard framework install, or will we need to
mess around with the PATH?

 

[Martin v. Löwis]

The Mac binary is giving a 404.

Thanks for pointing that out - it's fixed now.

Regards,
Martin

 

[Ben Finney]

On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.5.2 (release candidate 1).

Um. If it's only a release *candidate* of 2.5.2, and not yet a
*release* of 2.5.2, could you please announce it as something other
than a "release"?

It should either be announced as "the release of Python 2.5.2", if
that's the case; or "the availability of the Python 2.5.2 release
candidate 1".

 

[Martin v. Löwis]

On behalf of the Python development team and the Python community, I'm

Um. If it's only a release *candidate* of 2.5.2, and not yet a
*release* of 2.5.2, could you please announce it as something other
than a "release"?

It should either be announced as "the release of Python 2.5.2", if
that's the case; or "the availability of the Python 2.5.2 release
candidate 1".

Please accept my apologies. I'm not a native speaker, so "to release"
means to me what the dictionary says it means: m-w's fourth meaning,
"make available to the public". That's what I did - I made the release
candidate available to the public.

So is the subject incorrect as well? If so, what should it say?

Regards,
Martin

 

[Kevin Walzer]

Um. If it's only a release *candidate* of 2.5.2, and not yet a
*release* of 2.5.2, could you please announce it as something other
than a "release"?

It should either be announced as "the release of Python 2.5.2", if
that's the case; or "the availability of the Python 2.5.2 release
candidate 1".

This is splitting hairs. The subject clearly said "release candidate 1."
That means it's not the final candidate.

 

[Paul Rubin]

So is the subject incorrect as well? If so, what should it say?

Neither place is technically incorrect, but both are written in a way
that could give a slightly wrong impression.

It might be a little bit clearer to refer to the package as something
like Python 2.5.2-RC1, so you'd say "happy to announce the release of
Python 2.5.2-RC1" and similarly on the subject line; and in the
announcement text, say more clearly that what was just released is not
the final, official, Python 2.5.2 distribution; it's more like a late
beta test.

I thought the original announcement text was fine, but that may be
because I'm accustomed to the Python release cycle including the RC
releases.

 

[Ben Finney]

Please accept my apologies.

Thanks, but not needed. I'm merely trying to address the confusing
terminology in this announcement and future ones.

I'm not a native speaker, so "to release" means to me what the
dictionary says it means: m-w's fourth meaning, "make available to
the public". That's what I did - I made the release candidate
available to the public.

That's one meaning of the word, yes. But in the context of a free
software project with source code *always* available to the public
when it's announced, that meaning of "release" is an oxymoron.

A "release" is better understood in free software as exactly what the
"release candidate" is a candidate of: i.e. that it's always in some
form *available*, but it's not *released* until it's officially
blessed as "ready" in some way.

So is the subject incorrect as well? If so, what should it say?

It would be better if it didn't say "released" at all, since (as
discussed above) this isn't "released" except in the trivial
always-true sense that it is available.

Rather, it might just say "[ANN] Python 2.5.2, release candidate 1".

 

[Ben Finney]

I thought the original announcement text was fine, but that may be
because I'm accustomed to the Python release cycle including the RC
releases.

I think it's needlessly confusing to refer to a "release candidate
release"; that's almost an oxymoron. If it's a candidate for release,
then it's not yet a release.

Better to simply announce a release candidate, and reserve the term
"release" for a release (i.e. once the "release candidate" is accepted
as being ready for release).

 

[Ben Finney]

That's one meaning of the word, yes. But in the context of a free
software project with source code *always* available to the public
when it's announced, that meaning of "release" is an oxymoron.

Sorry, that should read "… that meaning of "release" is a tautology".

 

[Carl Banks]

Please accept my apologies. I'm not a native speaker, so "to release"
means to me what the dictionary says it means: m-w's fourth meaning,
"make available to the public". That's what I did - I made the release
candidate available to the public.

So is the subject incorrect as well? If so, what should it say?

I think it's fine as it is. You can "release" a release candidate.


Carl Banks

 

[Terry Reedy]

| It would be better if it didn't say "released" at all, since (as
| discussed above) this isn't "released" except in the trivial
| always-true sense that it is available.

I think this is slightly picky, but also correct.

| Rather, it might just say "[ANN] Python 2.5.2, release candidate 1".

So I agree, for the future (and no apologies for the present needed), that
this is a slightly better wording.

So, thanks to Martin for trying on the release manager role, and looking
forward to [ANN] Python 2.5.2 released.

tjr

 

[Ben Finney]

| Rather, it might just say "[ANN] Python 2.5.2, release candidate 1".

So I agree, for the future (and no apologies for the present
needed), that this is a slightly better wording.

So, thanks to Martin for trying on the release manager role, and
looking forward to [ANN] Python 2.5.2 released.

Agreed on all counts: no apology necessary, address the confusing
wording, and thanks to those doing the often-thankless work of release
management.

 

[Jeff Schwab]

I think it's fine as it is. You can "release" a release candidate.

You can, but it's confusing terminology. In the context of software
development, a release (PRODUCT_VERSION-RELEASE) is a different beast
from a release candidate (PRODUCT_VERSION-RC1).

 

[Paul Rubin]

You can, but it's confusing terminology. In the context of software
development, a release (PRODUCT_VERSION-RELEASE) is a different beast
from a release candidate (PRODUCT_VERSION-RC1).

I agree with this, I think the "release candidate" has indeed been
released in a nontrivial way and should get its own label like
2.5.2-RC1. It has characteristics that a random SVN snapshot doesn't
have, and in some situations there might be reasons to deploy
applications using it (e.g. applications relying on bug fixes that the
RC contains). Therefore the RC has to be labelled and archived for
purposes of tracing problems in any such applications, even if the RC
itself will not receive any support or back-fixes.

I join everyone else in thanking Martin for his work on this whole
effort. This wording and naming thing is a trivial subtopic.

 

[Jeff Schwab]

I join everyone else in thanking Martin for his work on this whole
effort. This wording and naming thing is a trivial subtopic.

Ditto! The list of fixes is impressive. Kudos to everyone who everyone
responsible for the changes, and for keeping them organized and documented.

 

[Luis M. González]

I join everyone else in thanking Martin for his work on this whole
effort. This wording and naming thing is a trivial subtopic.

Thanks Martin and company for the good job!
By the way, I'm not a native speaker either and I understood perfectly
the meaning of your post.

Luis

 

[Anthony Baxter]

So, thanks to Martin for trying on the release manager role, and looking
forward to [ANN] Python 2.5.2 released.

Hear, hear! Thanks to Martin for getting this out, and apologies from
me that it didn't happen sooner.