From: Michal Sojka <sojkam1@fel.cvut.cz>
To: Carl Worth <cworth@cworth.org>, Sebastian Spaeth <Sebastian@SSpaeth.de>,
	notmuch@notmuchmail.org
Subject: Re: [PATCH] Derive version numbers from git
In-Reply-To: <871veqrj9i.fsf@yoom.home.cworth.org>
References: <87hbnpo1yu.fsf@yoom.home.cworth.org>
	<87y6h16lun.fsf@steelpick.2x.cz> <87pr2c7pm1.fsf@SSpaeth.de>
	<87ochw7e8f.fsf@steelpick.2x.cz>
	<871veqrj9i.fsf@yoom.home.cworth.org>
Date: Thu, 08 Apr 2010 13:49:22 +0200
Message-ID: <87bpdu6u65.fsf@steelpick.2x.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

On Wed, 07 Apr 2010, Carl Worth wrote:
> On Tue, 06 Apr 2010 18:11:28 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
> >  On Tue, 06 Apr 2010, Sebastian Spaeth wrote:
> >
> >  > But, there are people without git installed that download the release
> >  > tarball. So if this patch makes it, we need to replace this with a
> >  > static version number when baking a release tar.
> > 
> > Right, here is an updated patch. It's more complicated than the previous
> > one, but it solves the issue.
> 
> I like this idea, definitely.
> 
> But the other piece needed here is a way for me to be able to specify a
> version in order to release. In my current release instructions
> (notmuch/RELEASING) I do that by manually incrementing the version
> number in the Makefile. Then a tag is created later when the "make
> release" target runs.

> It would be possible for me to instead create the tag to specify the
> version, but there's a few things I don't like about this:
> 
> 1. After I increment the version number (early in the release process) I
>    often find one or two little things I need to change to make the
>    release perfect. So there are likely more commits later, but I
>    obviously don't want some git-describe version to end up in the final
>    tar file.
> 
> 2. I don't actually want to create a tag, (I *especially* don't want to
>    push it), until the release actually happens. That's the point of the
>    tag in my view, (to say "*this* is what I released"), so making the
>    tag early seems wrong, (and leaves the door open to make mistakes).
> 
> Any suggestion for this part?

I have modified the patch slightly and I think that it could solve the
above points. The release process should be modified this way: you skip
point 5 (increment the notmuch version in Makefile.local) and in point
6, you run 'make release VERSION=X.Y'.

> > +include Makefile.version
> > +
> > +.PHONY: Makefile.version
> > +Makefile.version:
> > +	echo VERSION=$(if $(wildcard version),`cat version`,`git describe --dirty`) > $@
> 
> Could that be simplified to just use $(shell) rather than a separate
> file and an include?

Done. I have removed the --dirty option, because the dirty suffix
appeared every time I built debian package with git-buildpackage, and I
have added --match to match only release tags and not debian release
tags. That would probably mean that if you release the debian package
later than notmuch, the binary in debian package would have wrong
version compiled in. A solution could be that debian releases would live
in a different branch which will contain 'version' file and this branch
(and file) will be updated by make release.

> I suppose what we could do is to just have the creation of the version
> file be part of the release process. That would be simple enough. Then
> we could drop this rule:
> 
> > +version:
> > +	git describe > $@

I put it completely as part of TAR_FILE creation. If it was only
generated during release process, make dist would produce non-compilable
archives.

-Michal

--8<---------------cut here---------------start------------->8---
>From 26b9aad1143910a198c2d7263312f9b631edc022 Mon Sep 17 00:00:00 2001
From: Michal Sojka <sojkam1@fel.cvut.cz>
Date: Tue, 6 Apr 2010 18:01:43 +0200
Subject: [PATCH] Derive version numbers from git

I often have several versions of notmuch compiled and it would be very
helpful to be able to distinguish between them. Git has a very nice
feature to make intermediate numbering automatic and unambiguous so
let's use it here.

For tagged versions, the version is the name of the tag, for
intermediate versions, the unique ID of the commit is appended to the
tag name.

When notmuch is compiled from a release tarball, there is no git
repository and therefore the tarball contains a special file 'version',
which contains the version of release tarball.

To create a new release one has to run 'make release VERSION=X.Y'.
---
 Makefile.local |   15 +++++++++------
 1 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/Makefile.local b/Makefile.local
index 6882324..a26d6a0 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -7,11 +7,10 @@
 # digit when we reach particularly major milestones of usability.
 #
 # Between releases, (such as when compiling notmuch from the git
-# repository), we add a third digit, (0.1.1, 0.1.2, etc.), and
-# increment it occasionally, (such as after a big batch of commits are
-# merged.
+# repository), we let git to append identification of the actual
+# commit.
 PACKAGE=notmuch
-VERSION=0.1.1
+VERSION:=$(shell if [ -f version ]; then cat version; else git describe --match '[0-9].[0-9]*'; fi)
 
 RELEASE_HOST=notmuchmail.org
 RELEASE_DIR=/srv/notmuchmail.org/www/releases
@@ -63,7 +62,11 @@ endif
 endif
 
 $(TAR_FILE):
-	git archive --format=tar --prefix=$(PACKAGE)-$(VERSION)/ HEAD | gzip > $(TAR_FILE)
+	git archive --format=tar --prefix=$(PACKAGE)-$(VERSION)/ HEAD > $(TAR_FILE).tmp
+	echo $(VERSION) > version
+	tar --append -f $(TAR_FILE).tmp --transform s_^_$(PACKAGE)-$(VERSION)/_ version
+	rm version
+	gzip < $(TAR_FILE).tmp > $(TAR_FILE)
 	@echo "Source is ready for release in $(TAR_FILE)"
 
 $(SHA1_FILE): $(TAR_FILE)