[Distutils] post-release revisions

[Ben Finney]

"P.J. Eby" <pje at telecommunity.com> writes:

> That depends on whether this PEP's version scheme is also going to be
> embedded in the code implied by PEP 376. If so, then nobody will have
> any reason to switch from using pkg_resources to the PEP 376 pkgutil
> code, because they won't be able to manage their test, dev, and
> collaboration environments that way.

What prevents them from doing so merely by choosing version strings that
conform to the specification?

> That's precisely it - there aren't any visible benefits to doing so,
> but there *are* visible problems.

I think a significant benefit will be that the version comparison
semantics will be implemented *in Python*, and I know there are very
many people who would like to drop a dependency on third-party tools.

Alternatively, if this version string scheme is to be implemented in PEP
365, that has the same effect: it will be “part of Python”, which is a
huge benefit compared to an implementation outside Python.

> We need to have a way to translate existing version schemes to the new
> one, if we're to be able to have a reasonable upgrade path --

This certainly deserves consideration. However, I remind readers that
part of the problem we're trying to solve here is that version string
schemes are *already* non-standard and inconsistent; we would have to
choose only a sub-set of existing version schemes to be supported for
upgrade.

-- 
 \              “In the long run, the utility of all non-Free software |
  `\      approaches zero. All non-Free software is a dead end.” —Mark |
_o__)                                                    Pilgrim, 2006 |
Ben Finney