[Distutils] PEP 386 and git versioning scheme

[Daniel Holth]

On Sat, Feb 16, 2013 at 8:26 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

>
> On 17 Feb 2013 05:11, "Chris Withers" <chris at simplistix.co.uk> wrote:
> >
> > On 28/01/2013 18:21, Manlio Perillo wrote:
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Hi.
> >>
> >> In a project I'm working on, I use git, and I'm trying to follow the
> >> versioning scheme used by the git project (since it is very pratical).
> >>
> >> To summarize, git version is generated from the output of
> >> "git describe" command, replacing the '-' character with '.'.
> >>
> >> git describe returns a string formed by using the most recent tag
> >> (e.g. 1.8.1, 1.8.1.rc1), and adding the number of revisions after that
> >> tag, and the short ID of the current revision
> >> (e.g v1.8.1-301-ga0df26f).
> >>
> >> So, a version may be something like: v1.8.1.301.ga0df26f
> >>
> >> It seems that this versioning scheme is not compatible with PEP 386 "new
> >> versioning scheme". Is this true?
> >
> >
> > I hope not, can someone comment on this?
> >
> > We need to deal with hashes-in-versions as both Git and Mercurial are
> likely to have this...
>
> It's deliberately incompatible - we don't want installers (for wheel in
> particular) to have to guess about the version ordering for every
> versioning scheme on the planet.
>
> However, I now plan to add a "Private-Version" field which will be an
> arbitrary version label. So projects will be free to use whatever internal
> versioning scheme they want, so long as they (or, more accurately, their
> distribution tools) also translate it to a standard version for use with
> version specifiers.
>
> That's actually already the case, but the new field will make it clearer
> and more transparent.
>
> Cheers,
> Nick.
>
I would think of a git^Wmercurial ID used as the last version component a
"non-sorting string". It is never intended to actually break a tie between
two versions; if you do wind up using it to sort then you are in trouble
(two people published a development version that happened to be n commits
above the last tag...). The last component only tells you that 1.8.1.301.x
and 1.8.1.301.y are not the same version, not that one should be greater or
less than the other.

I am OK with the PEP 386 restrictions.

You can convert git's hex id to decimal ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130216/e9d068ea/attachment.html>