[Distutils] post-release revisions

[Paul Moore]

2009/6/11 Eric Smith <eric at trueblade.com>:
> I think this is an excellent point, and I think that both ways of doing it
> need to be supported. The "counting up" method is especially useful if
> you're moving toward 2 different versions, simultaneously. Think about
> Python itself moving to 3.0. What should development versions of Python 3.0
> have been called, when both 2.6 and 3.0 were being developed? If only
> "counting away" were supported, would all 3.0 build have been called
> "alpha"? Certainly calling 2.6 and 3.0 "2.5 plus something" would have been
> wrong, and a nightmare.

They weren't called anything (OK, internally all such releases have
version number 2.6a0 and 3.0a0 respectively, but individual Subversion
commits had no distinct version). And that's precisely right, as they
are internal commits, and were not released.

Why is there a need for every internal commit to have a distinct
"version number"? I'm not saying there's no need to be able to
identify the code base, but why must everything be lumped into the
version? In my experience (and in the practice used by Python core)
version numbers are for released versions. Snapshots, nightly builds,
personal developer builds, etc, don't have version numbers.

> True. When I'm "sneaking up" on an alpha release, I need to have version
> comparisons work in my test environment, and I'd prefer to use "-dev". These
> releases would never be published to PyPI or anywhere else, other than my
> internal servers.

I'm sorry, but why? How does your test environment work so that you
are testing 2 versions at once, and need to compare "version numbers"
programmatically? And why isn't something *additional* to the version
number, like the core's sys.subversion, suitable?

Please note, in case I seem excessively aggressive - my assumption is
that the standard defined by the PEP doesn't have to be used by
everyone, in all cases. You presumably have code that works at the
moment, and you are perfectly entitled to continue using it. If you
switch to the APIs proposed in the PEP, then presumably you see some
benefits in following the standard. There's clearly a cost in doing so
- one part of the cost is changing your code, and I don't think it's
unreasonable for another part of that cost to be changing your version
numbering scheme (at least for your released versions). Whether that
cost is too high is a decision you have to make yourself. Designing
the PEP is a compromise between all the various aspects involved.

Paul.