Notmuch release 0.1 now available

Notmuch release 0.1 now available

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 2037 bytes --]

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.

For example, I just released notmuch 0.1, current git clone will
create notmuch 0.1.1, and the next anticipated release will be 0.2.

The first release announcement is below, with very thin release notes. I
hope to have better release announcements in the future. For this, I'll
need the help of all contributors. Here's my request:

	When you submit a patch adding a new feature to notmuch, please
	include with it an edit to the NEWS file adding a sentence or
	paragraph to the top of that file.

Thanks, and have fun out there.

-Carl

Where to obtain notmuch 0.1
===========================
  http://notmuchmail.org/releases/notmuch-0.1.tar.gz

Which can be verified with:

  http://notmuchmail.org/releases/notmuch-0.1.tar.gz.sha1
  fa390b7e652bebbdd5c178a60d8056e662df03ba  notmuch-0.1.tar.gz

  http://notmuchmail.org/releases/notmuch-0.1.tar.gz.sha1.asc
  (signed by Carl Worth)

What's new in notmuch 0.1
=========================
This is the first release of the notmuch mail system.

It includes the libnotmuch library, the notmuch command-line
interface, and an emacs-based interface to notmuch.

Note: Notmuch will work best with Xapian 1.0.18 (or later) or Xapian
1.1.4 (or later). Previous versions of Xapian (whether 1.0 or 1.1) had
a performance bug that made notmuch very slow when modifying
tags. This would cause distracting pauses when reading mail while
notmuch would wait for Xapian when removing the "inbox" and "unread"
tags from messages in a thread.

What is notmuch
===============
Notmuch is a system for indexing, searching, reading, and tagging
large collections of email messages in maildir or mh format. It uses
the Xapian library to provide fast, full-text search with a convenient
search syntax.

For more about notmuch, see http://notmuchmail.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[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

[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

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

Re: [PATCH] Derive version numbers from git

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 2046 bytes --]

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?

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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 <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)

Re: [PATCH] Derive version numbers from git

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

On Thu, 08 Apr 2010 13:49:22 +0200, Michal Sojka <sojkam1@fel.cvut.cz> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]