Re: how to properly define version number of a package using git+COMMITID in the version?

[Sebastian Kuzminsky <seb@highlab.com>]

On 02/02/2018 09:14 AM, James Clarke wrote:
> On 2 Feb 2018, at 16:07, Sébastien Villemot <sebastien@debian.org> wrote:
> > On Fri, Feb 02, 2018 at 04:23:37PM +0100, Christophe Trophime wrote:
> > > Hi,
> > > I would like to update a package feelpp from its latest release 0.103.2 to a more recent development version.
> > > I've tried to define the newest version as: 0.103.3+gitREVNUMBER with REVNUMBER the id of the git commit
> > >
> > > The trouble is that when trying to update locally my package which are stored in a local repo
> > > apt still wants to install 0.103.2 version instead of the newest 0.103.3+gitREVNUMBER
> > >
> > > What do I miss to get the dev version to be installed?
> >
> > Since 0.103.3+gitREVNUMBER > 0.103.2 (can be easily checked with "dpkg --compare-versions"),
> > the problem does not come from versioning, but more likely from apt pinning.
>
> Whilst that version number does compare fine, it's likely to be problematic for
> any future development versions, since 0.103.3+git0123456 sorts before
> 0.103.3+gitfedcba9, even though 0123456 may be a newer commit. To avoid this,
> it's common to include the date of the commit in the version number, often as
> 0.103.3+YYYYMMDD.gitREVNUMBER.

Another option is to use "git describe", which can be made to give you:

${MOST_RECENT_TAG}-${NUMBER_OF_COMMITS_SINCE_TAG}-g${SHA}

In your example it might be "0.103.2-45-g0123456", which has the 
properties you want from a version number (after you translate the "-" 
characters to ".".

You can use --match to select what tags to pay attention to, for example 
"release/*".


--
Sebastian Kuzminsky