On Fri, Oct 09, 2009 at 01:24:50PM -0000, exarkun@twistedmatrix.com wrote:
On 12:25 pm, benji@zope.com wrote:
On Thu, Oct 8, 2009 at 6:40 PM, Zooko Wilcox-O'Hearn <zooko@zooko.com> wrote:
What we do in the Tahoe-LAFS project is we don't count down to a future version, we only count up from a past version. ?This is also what Twisted does (no coincidence -- we probably got the idea from them).
To clarify: that means that a beta for 2.0.0 might have a version of 1.6.3-r4321?
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.
The pre-release would become 2.0.0.dev1 in the proposed PEP386 spec I guess, however the suggest_rational_version() function suggests otherwise:
verlib.suggest_rational_version('2.0.0pre1') '2.0.0c1'
It interprets your version string as a "release candidate" version, which it actually might be given that you gave it it a number of "1" and not some longer revision-control based one. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org