Zooko Wilcox-O'Hearn wrote:
Trent Mick:
Thank you very much for the summary emails.
Indeed!
This gives us:
N.N.NaN # e.g. "1.0.0a2"
N.N.NbN # e.g. "2.6.0b1"
This is where we branch between the two ways that people do it. Some
people count up to a future release, other people count away from past
releases. (Of course probably some people do both.)
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.
[From another thread]
P.J. Eby wrote:
> PyPI uploads aren't a suitable basis for analyzing "dev" use cases,
> since the whole point of having a "dev" tag is for *non-released*
> versions. (E.g., in-progress development via SVN.) Dev tags are so
> that while you're doing development, your locally-installed versions can
> be distinguished from one another.
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.
Eric.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
