Re: [PATCH] Derive version numbers from git

[Carl Worth]

On Thu, 08 Apr 2010 13:49:22 +0200, Michal Sojka  wrote:
> On Wed, 07 Apr 2010, Carl Worth wrote:
> 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'.

Looks great. I've pushed that now and updated the instructions in
RELEASING.

It occurs to me that I'm already updating the version in the NEWS file,
so the next step would be to just make "make release" get it from there.

But in the meantime, having these nice git-describe-generated version
numbers will be quite handy (86 commits since 0.1 already, wow!). So,
thanks!

-Carl


pgpdpwy7lDzus.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] Derive version numbers from git

[Carl Worth]

On Thu, 08 Apr 2010 13:49:22 +0200, Michal Sojka  wrote:
> On Wed, 07 Apr 2010, Carl Worth wrote:
> 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'.

Looks great. I've pushed that now and updated the instructions in
RELEASING.

It occurs to me that I'm already updating the version in the NEWS file,
so the next step would be to just make "make release" get it from there.

But in the meantime, having these nice git-describe-generated version
numbers will be quite handy (86 commits since 0.1 already, wow!). So,
thanks!

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[PATCH] Derive version numbers from git

[Michal Sojka]

On Wed, 07 Apr 2010, Carl Worth wrote:
> On Tue, 06 Apr 2010 18:11:28 +0200, Michal Sojka  
> 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 
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

Re: [PATCH] Derive version numbers from git

[Michal Sojka]

On Wed, 07 Apr 2010, Carl Worth wrote:
> On Tue, 06 Apr 2010 18:11:28 +0200, Michal Sojka  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 
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/not

Re: [PATCH] Derive version numbers from git

[Carl Worth]

On Tue, 06 Apr 2010 18:11:28 +0200, Michal Sojka  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?

> +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?

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 > $@

What do you think?

-Carl


pgpi44BjuRLiB.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] Derive version numbers from git

[Carl Worth]

On Tue, 06 Apr 2010 18:11:28 +0200, Michal Sojka  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?

> +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?

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 > $@

What do you think?

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[PATCH] Derive version numbers from git

[Michal Sojka]

 On Tue, 06 Apr 2010, Sebastian Spaeth wrote:
 > On 2010-04-06, Michal Sojka wrote:
 > > 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.
 > 
 > 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.

-Michal


--8<---cut here---start->8---
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 has to contain a special file
'version', which contains the correct version number.
---
 .gitignore |1 +
 Makefile.local |   24 +---
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/.gitignore b/.gitignore
index 95c50ec..b72ce72 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,5 +1,6 @@
 .first-build-message
 Makefile.config
+Makefile.version
 TAGS
 tags
 *cscope*
diff --git a/Makefile.local b/Makefile.local
index 74f0f86..09fffa6 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -7,11 +7,14 @@
 # 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
+include Makefile.version
+
+.PHONY: Makefile.version
+Makefile.version:
+   echo VERSION=$(if $(wildcard version),`cat version`,`git describe 
--dirty`) > $@

 RELEASE_HOST=notmuchmail.org
 RELEASE_DIR=/srv/notmuchmail.org/www/releases
@@ -61,8 +64,15 @@ ifeq ($(shell cat .first-build-message),)
 endif
 endif

-$(TAR_FILE):
-   git archive --format=tar --prefix=$(PACKAGE)-$(VERSION)/ HEAD | gzip > 
$(TAR_FILE)
+.PHONY: version # Always regenerate version
+version:
+   git describe > $@
+
+$(TAR_FILE): version
+   git archive --format=tar --prefix=$(PACKAGE)-$(VERSION)/ HEAD > 
$(TAR_FILE).tmp
+   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)
@@ -263,4 +273,4 @@ install-zsh:
$(call quiet_install_data, contrib/notmuch-completion.zsh 
$(DESTDIR)$(zsh_completion_dir)/notmuch)

 SRCS  := $(SRCS) $(notmuch_client_srcs)
-CLEAN := $(CLEAN) notmuch notmuch-shared $(notmuch_client_modules) notmuch.elc 
notmuch.1.gz
+CLEAN := $(CLEAN) notmuch notmuch-shared $(notmuch_client_modules) notmuch.elc 
notmuch.1.gz version
-- 
1.7.0.2

[PATCH] Derive version numbers from git

[Sebastian Spaeth]

On 2010-04-06, Michal Sojka wrote:
> 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.

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.

Sebastian

[PATCH] Derive version numbers from git

[Michal Sojka]

On Tue, 06 Apr 2010, Carl Worth wrote:
> In trying to get notmuch to grow up a little bit, I've just added a
> version number (0.1 initially) and have started doing releases. My idea
> for now is to have 2-part versions for releases, and 3-part versions to
> indicate intermediate states within git.

Hi Carl,

first of all, thank you very much for the first release. I think, that
0.1 is good number to start with, but I do not like manual numbering of
intermediate states. Please, consider applying the following patch.

-Michal

- >8  >8 -
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.

diff --git a/Makefile.local b/Makefile.local
index 74f0f86..890f78a 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 git describe --dirty)

 RELEASE_HOST=notmuchmail.org
 RELEASE_DIR=/srv/notmuchmail.org/www/releases

Re: [PATCH] Derive version numbers from git

[Michal Sojka]

 On Tue, 06 Apr 2010, Sebastian Spaeth wrote:
 > On 2010-04-06, Michal Sojka wrote:
 > > 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.
 > 
 > 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.

-Michal

 
--8<---cut here---start->8---
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 has to contain a special file
'version', which contains the correct version number.
---
 .gitignore |1 +
 Makefile.local |   24 +---
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/.gitignore b/.gitignore
index 95c50ec..b72ce72 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,5 +1,6 @@
 .first-build-message
 Makefile.config
+Makefile.version
 TAGS
 tags
 *cscope*
diff --git a/Makefile.local b/Makefile.local
index 74f0f86..09fffa6 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -7,11 +7,14 @@
 # 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
+include Makefile.version
+
+.PHONY: Makefile.version
+Makefile.version:
+   echo VERSION=$(if $(wildcard version),`cat version`,`git describe 
--dirty`) > $@
 
 RELEASE_HOST=notmuchmail.org
 RELEASE_DIR=/srv/notmuchmail.org/www/releases
@@ -61,8 +64,15 @@ ifeq ($(shell cat .first-build-message),)
 endif
 endif
 
-$(TAR_FILE):
-   git archive --format=tar --prefix=$(PACKAGE)-$(VERSION)/ HEAD | gzip > 
$(TAR_FILE)
+.PHONY: version # Always regenerate version
+version:
+   git describe > $@
+
+$(TAR_FILE): version
+   git archive --format=tar --prefix=$(PACKAGE)-$(VERSION)/ HEAD > 
$(TAR_FILE).tmp
+   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)
@@ -263,4 +273,4 @@ install-zsh:
$(call quiet_install_data, contrib/notmuch-completion.zsh 
$(DESTDIR)$(zsh_completion_dir)/notmuch)
 
 SRCS  := $(SRCS) $(notmuch_client_srcs)
-CLEAN := $(CLEAN) notmuch notmuch-shared $(notmuch_client_modules) notmuch.elc 
notmuch.1.gz
+CLEAN := $(CLEAN) notmuch notmuch-shared $(notmuch_client_modules) notmuch.elc 
notmuch.1.gz version
-- 
1.7.0.2
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] Derive version numbers from git

[Sebastian Spaeth]

On 2010-04-06, Michal Sojka wrote:
> 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.

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.

Sebastian
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] Derive version numbers from git

[Michal Sojka]

On Tue, 06 Apr 2010, Carl Worth wrote:
> In trying to get notmuch to grow up a little bit, I've just added a
> version number (0.1 initially) and have started doing releases. My idea
> for now is to have 2-part versions for releases, and 3-part versions to
> indicate intermediate states within git.

Hi Carl,

first of all, thank you very much for the first release. I think, that
0.1 is good number to start with, but I do not like manual numbering of
intermediate states. Please, consider applying the following patch.

-Michal

- >8  >8 -
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.

diff --git a/Makefile.local b/Makefile.local
index 74f0f86..890f78a 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 git describe --dirty)
 
 RELEASE_HOST=notmuchmail.org
 RELEASE_DIR=/srv/notmuchmail.org/www/releases
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch