[email protected] wrote:
I'm not sure how zooko does this for Tahoe, but with Twisted (with which
we don't do "betas" but we do do "pre-releases") if we were to start
getting ready for 2.0.0, then we would create a release branch and
change the version in that release branch to 2.0.0pre1. This, of
course, complicates the matter. :) I don't think anyone has considered
how our pre-release version numbers sort compared to the rest of our
version numbers. After 2.0.0 final is released, we merge the release
branch back into trunk, changing the trunk version to 2.0.0-r54321.
I beg you to make sure that whatever ends up in the python core to do
with sorting and comparing version numbers takes your use case into
account. I like the way you do things :-)
(rare I say that about Twisted ;-) )
I'm -1 on "0" or any other special-case singleton version number...
I'm +1 on the branch having a version of 1.6.3~dev after 1.6.3 has been
released, and I like 2.0.0pre1 too :-)
Moreover, I wish we could just get a bdfl pronouncement on something
that works for everyone and get on with it :-D
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
