Here are the steps to follow to create a new notmuch release. 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. 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. 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). 2) Verify that the library version in lib/Makefile.local is correct See the instructions there for how to increment it. The version should have been updated with any commits that added API, but do check that that is the case. The command below can be useful for inspecting header-file changes since the last release X.Y: git diff X.Y..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, if any. 3) Upgrade the version in the file "version" The scheme for the release number is as follows: A major milestone in usability causes an increase in the major number, yielding a two-component version with a minor number of 0, (such as "1.0" or "2.0"). Otherwise, releases with changes in features cause an increase in the minor number, yielding a two-component version, (such as "1.1" or "1.2"). Finally, releases that do not change "features" but are merely bug fixes either add increase the micro number or add it (starting at ".1" if not present). So a bug-fix release from "1.0" would be "1.0.1" and a subsequent bug-fix release would be "1.0.2" etc. Commit this change. 4) Create an entry for the new release in debian/changelog The syntax of this file is tightly restricted, but the available emacs mode (see the dpkg-dev-el package helps). The entries here will be the Debian-relevant single-line description of changes from the NEWS entry. And the version must match the version in the next step. Commit this change. XXX: It would be great if this step were automated as part of release, (taking entries from NEWS and the version from the version file, and creating a new commit, etc.) 5) Run "make release" which will perform the following steps: * Ensure that the version consists only of digits and periods * Verify that the source tree is clean * Compile the current notmuch code (aborting release if it fails) * Run the notmuch test suite (aborting release if it fails) * Generate the final tar file * Generate a .sha1 sum file for the tar file * Sign the sha1sum using your GPG setup (asks for your GPG password) * Check that no release exists with the current version * scp the three files to appear on http://notmuchmail.org/releases * Create a LATEST-notmuch-version file (after deleting any old one) * Place local copies of the three files in the releases directory * 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.) * Push that tag * Provide some text for the release announcement (see below). 6) Send a message to notmuch@notmuchmail.org to announce the release. Use the text provided from "make release" above, (if for some reason you lose this message, "make release-message" prints it again for you.