2010-04-16 04:55:11 +02:00
|
|
|
Here are the steps to follow to create a new notmuch release.
|
2010-04-06 00:00:37 +02:00
|
|
|
|
2010-04-16 04:55:11 +02:00
|
|
|
These steps assume that a process (not described here) has already
|
|
|
|
been followed to determine the features and bug fixes to be included
|
|
|
|
in a release, and that adequate testing by the community has already
|
|
|
|
been performed. The little bit of testing performed here is a safety
|
|
|
|
check, and not a substitute for wider testing.
|
2010-04-06 00:00:37 +02:00
|
|
|
|
2010-04-16 04:55:11 +02:00
|
|
|
OK, so the code to be released is present and committed to your git
|
|
|
|
repository. From here, there are just a few steps to release:
|
|
|
|
|
|
|
|
1) Verify that the NEWS file is up to date.
|
2010-04-06 00:00:37 +02:00
|
|
|
|
|
|
|
Read through the entry at the top of the NEWS file and see if
|
|
|
|
you are aware of any major features recently added that are
|
|
|
|
not mentioned there. If so, pleas add them, (and ask the
|
|
|
|
authors of the commits to update NEWS in the future).
|
|
|
|
|
2010-04-16 04:55:11 +02:00
|
|
|
2) Increment the libnotmuch library version in lib/Makefile.local
|
2010-04-06 00:00:37 +02:00
|
|
|
|
|
|
|
See the instructions there for how to increment it. The
|
|
|
|
command below can be useful for inspecting header-file changes
|
|
|
|
since the last release X.Y.Z:
|
|
|
|
|
|
|
|
git diff X.Y.Z..HEAD -- lib/notmuch.h
|
|
|
|
|
|
|
|
Note: We currently don't plan to increment
|
|
|
|
LIBNOTMUCH_VERSION_MAJOR beyond 1, so if there *are*
|
|
|
|
incompatible changes to the library interface, then
|
|
|
|
stop. Don't release. Figure out the plan on the notmuch
|
|
|
|
mailing list.
|
|
|
|
|
|
|
|
Commit this change.
|
|
|
|
|
2010-04-16 04:55:11 +02:00
|
|
|
3) Run "make VERSION=X.Y release" which will perform the following steps:
|
2010-04-06 00:00:37 +02:00
|
|
|
|
2010-04-10 04:12:36 +02:00
|
|
|
For the X.Y version, we'll generally just increment Y. But for
|
|
|
|
major milestones of usability we're increment X as well.
|
2010-04-06 00:00:37 +02:00
|
|
|
|
2010-04-16 05:03:30 +02:00
|
|
|
* Ensure that the caller passed VERSION=X.Y
|
|
|
|
* Verify that the source tree is clean
|
2010-04-16 01:08:37 +02:00
|
|
|
* Compile the current notmuch code (aborting release if it fails)
|
|
|
|
* Run the notmuch test suite (aborting release if it fails)
|
2010-04-06 00:00:37 +02:00
|
|
|
* Generate the final tar file
|
2010-04-16 05:03:30 +02:00
|
|
|
* Generate a .sha1 sum file for the tar file
|
2010-04-06 00:00:37 +02:00
|
|
|
* Sign the sha1sum using your GPG setup (asks for your GPG password)
|
2010-04-16 05:03:30 +02:00
|
|
|
* Check that no release exists with the current version
|
2010-04-06 00:00:37 +02:00
|
|
|
* scp the three files to appear on http://notmuchmail.org/releases
|
|
|
|
* Create a LATEST-notmuch-version file (after deleting any old one)
|
2010-04-16 05:03:30 +02:00
|
|
|
* Place local copies of the three files in the releases directory
|
2010-04-06 00:00:37 +02:00
|
|
|
* Tag the entire source tree with a tag of the form X.Y.Z, and sign
|
|
|
|
the tag with your GPG key (asks for your GPG password, and you
|
|
|
|
may need to set GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL to match
|
|
|
|
your public-key's setting or this fails.)
|
2010-04-06 00:56:23 +02:00
|
|
|
* Push that tag
|
2010-04-06 00:00:37 +02:00
|
|
|
* Provide some text for the release announcement (see below).
|
|
|
|
|
2010-04-16 04:55:11 +02:00
|
|
|
4) Send a message to notmuch@notmuchmail.org to announce the release.
|
2010-04-06 00:00:37 +02:00
|
|
|
|
2010-04-10 04:12:36 +02:00
|
|
|
Use the text provided from "make release" above, (if for some
|
|
|
|
reason you lose this message, "make release-message" prints
|
|
|
|
it again for you.
|