[Distutils] post-release revisions (was: recollections of Pycon distutils versioning discussion (part 1))

[Paul Moore]

2009/6/11 Zooko Wilcox-O'Hearn <zooko at zooko.com>:
>
> 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.)
>
> In Tahoe (and I think in Twisted, and Nevow, and Foolscap), we typically
> don't count up to a release so that $REL-$SOMETHING is a predecessor to the
> $REL release.  Instead we count away from $REL, so that $REL-$SOMETHING is a
> successor to the $REL release.
>
> Here's an example:
>
> http://allmydata.org/source/tahoe/tarballs/
>
> There are files in that directory named allmydata-tahoe-1.4.1-r3904.tar.gz,
> allmydata-tahoe-1.4.1-r3905.tar.gz, allmydata-tahoe-1.4.1-r3908.tar.gz, etc.
>  Each of these is newer than the previous one, and all of them are newer
> than the v1.4.1 release.

So just go with 1.4.1.3908

> So, we don't use the "a/b/c" indicators, but we do use what you are calling
> "post-release" indicators.  Currently that is spelled "-r", which is how
> Tahoe, Twisted, and setuptools do it.  At PyCon I agreed that it wouldn't
> hurt to change the spelling to "-post" for clarity and for parallelism with
> "-pre".  (I don't have the authority to agree to anything on behalf of the
> Twisted or setuptools projects -- I was just agreeing to stop arguing about
> it.  :-))

If it's just arguing about which spelling to use, there should be
nothing wrong with "." rather than "-r", and it has the huge
advantages of simplicity and consistency.

Actually, using Ben's (slightly) extended definition, you could even
use ".r" if you're wedded to the idea of having something other than a
plain number.

Paul.