* Notmuch release 0.1 now available @ 2010-04-06 0:32 Carl Worth 2010-04-06 8:12 ` [PATCH] Derive version numbers from git Michal Sojka 0 siblings, 1 reply; 7+ messages in thread From: Carl Worth @ 2010-04-06 0:32 UTC (permalink / raw) To: notmuch [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] Derive version numbers from git 2010-04-06 0:32 Notmuch release 0.1 now available Carl Worth @ 2010-04-06 8:12 ` Michal Sojka 2010-04-06 12:05 ` Sebastian Spaeth 0 siblings, 1 reply; 7+ messages in thread From: Michal Sojka @ 2010-04-06 8:12 UTC (permalink / raw) To: Carl Worth, notmuch 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] Derive version numbers from git 2010-04-06 8:12 ` [PATCH] Derive version numbers from git Michal Sojka @ 2010-04-06 12:05 ` Sebastian Spaeth 2010-04-06 16:11 ` Michal Sojka 0 siblings, 1 reply; 7+ messages in thread From: Sebastian Spaeth @ 2010-04-06 12:05 UTC (permalink / raw) To: Michal Sojka, Carl Worth, notmuch 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Derive version numbers from git 2010-04-06 12:05 ` Sebastian Spaeth @ 2010-04-06 16:11 ` Michal Sojka 2010-04-07 22:27 ` Carl Worth 0 siblings, 1 reply; 7+ messages in thread From: Michal Sojka @ 2010-04-06 16:11 UTC (permalink / raw) To: Sebastian Spaeth, Carl Worth, notmuch 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] Derive version numbers from git 2010-04-06 16:11 ` Michal Sojka @ 2010-04-07 22:27 ` Carl Worth 2010-04-08 11:49 ` Michal Sojka 0 siblings, 1 reply; 7+ messages in thread From: Carl Worth @ 2010-04-07 22:27 UTC (permalink / raw) To: Michal Sojka, Sebastian Spaeth, notmuch [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Derive version numbers from git 2010-04-07 22:27 ` Carl Worth @ 2010-04-08 11:49 ` Michal Sojka 2010-04-10 2:20 ` Carl Worth 0 siblings, 1 reply; 7+ messages in thread From: Michal Sojka @ 2010-04-08 11:49 UTC (permalink / raw) To: Carl Worth, Sebastian Spaeth, notmuch 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) ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] Derive version numbers from git 2010-04-08 11:49 ` Michal Sojka @ 2010-04-10 2:20 ` Carl Worth 0 siblings, 0 replies; 7+ messages in thread From: Carl Worth @ 2010-04-10 2:20 UTC (permalink / raw) To: Michal Sojka, Sebastian Spaeth, notmuch [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-04-10 2:20 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-04-06 0:32 Notmuch release 0.1 now available Carl Worth 2010-04-06 8:12 ` [PATCH] Derive version numbers from git Michal Sojka 2010-04-06 12:05 ` Sebastian Spaeth 2010-04-06 16:11 ` Michal Sojka 2010-04-07 22:27 ` Carl Worth 2010-04-08 11:49 ` Michal Sojka 2010-04-10 2:20 ` Carl Worth
Code repositories for project(s) associated with this public inbox https://yhetil.org/notmuch.git/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).