[Python-Dev] no remaining issues blocking 2.5 release

["Martin v. Löwis"]

Guido van Rossum schrieb:
> I am sympathetic to this case. Is there any advantage to the *users*
> of distutils of the dynamic version number?

This series of commits was triggered by a user who wondered why
Python 2.4.3 ships with distutils 2.4.1, yet Python 2.5bsomething
ships with the older 2.4.0; he requested that the newer release
of distutils should be included in Python 2.5.

So the advantage to the user is that the distutils version numbers
become less confusing, and more "correct" (as long as the packaged
distutils is used).

> If it's only done for the
> benefit of the release managers (with whose plight I also
> sympathesize)

In principle, the release manager shouldn't be the one updating
the distutils release number. Instead, whoever modifies distutils
needs to decide whether this change is a bug fix (subminor change)
or feature change (minor number changes).

> I think it must be rolled back, at least as long as
> distutils is officially listed as a package that needs to support
> older versions of Python, which pretty much implies that it's okay to
> extract it from the 2.5 release and distribute it separately for use
> with older Python versions.

See, it isn't listed as such anymore, not since AMK removed it from
PEP 291.

That said, I'm not terribly opposed to it being changed back (*) - but
*I* won't change it back (having it changed already twice in two
days). I just wish I could then delegate all bug reports "distutils
doesn't work with older Python releases" to MAL. As far as I'm
concerned, this isn't a distutils feature anymore.

Regards,
Martin

(*) where "back" means 2.5.0, not 2.4.0.