Re: Please test tarsnap 1.0.37

[Graham Percival <gperciva@tarsnap.com>]

On Fri, Mar 11, 2016 at 05:20:10PM +0200, Shinnok wrote:
> > On Mar 8, 2016, at 2:35 AM, Colin Percival <cperciva@tarsnap.com> wrote:
> > I didn't want to tag anything yet in case someone saw "1.0.37" and thought
> > that it was released.
> 
> I see the 1.0.37 tagged on 71b3f4e:
> https://github.com/Tarsnap/tarsnap/releases/tag/1.0.37
> 
> However after checkout and autoreconf && rebuild:
> $./tarsnap --version
> tarsnap 1.0.36-head

The -head part is Tarsnap policy:

$ git log --format=short -1 71923
commit 7192300dfc82e5c13c496e6b3f7f550e7f98bcfc
Author: Colin Percival <cperciva@tarsnap.com>

    Mark version as -head when built from git tree


When an official tarball is generated, it gets a release number without -head.

> Shouldn't the tagged head have those files use the new version?

I agree that it might be less confusing in some circumstances if the tag was
one commit later; i.e. 1.0.36 would be tagged e5e86a5e instead of 13d3e3116,
and 1.0.37 would be e8ac80744 instead of 71b3f4e.

However, I believe that Colin's argument is that the tag should reflect
exactly the state of the git tree when he ran:
    sh release-tools/mktarball.sh 1.0.37

As such, the contents of `tar-version` will be one less than the official
release number, which is added in the `mktarball.sh` phase.

Cheers,
- Graham