[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Please test tarsnap 1.0.37
On Fri, Mar 11, 2016 at 05:20:10PM +0200, Shinnok wrote:
> > On Mar 8, 2016, at 2:35 AM, Colin Percival <email@example.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:
> 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
Author: Colin Percival <firstname.lastname@example.org>
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.