[Distutils] dev versions

[Floris Bruynooghe]

On Fri, Oct 09, 2009 at 01:24:50PM -0000, exarkun at twistedmatrix.com wrote:
> On 12:25 pm, benji at zope.com wrote:
> >On Thu, Oct 8, 2009 at 6:40 PM, Zooko Wilcox-O'Hearn
> ><zooko at 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