git.notmuchmail.org Git - notmuch/blob - RELEASING

   1 Here are the steps to follow to create a new notmuch release.
   2
   3 These steps assume that a process (not described here) has already
   4 been followed to determine the features and bug fixes to be included
   5 in a release, and that adequate testing by the community has already
   6 been performed. The little bit of testing performed here is a safety
   7 check, and not a substitute for wider testing.
   8
   9 OK, so the code to be released is present and committed to your git
  10 repository. From here, there are just a few steps to release:
  11
  12 1) Verify that the NEWS file is up to date.
  13
  14         Read through the entry at the top of the NEWS file and see if
  15         you are aware of any major features recently added that are
  16         not mentioned there. If so, pleas add them, (and ask the
  17         authors of the commits to update NEWS in the future).
  18
  19 2) Verify that the library version in lib/Makefile.local is correct
  20
  21         See the instructions there for how to increment it.
  22
  23         The version should have been updated with any commits that
  24         added API, but do check that that is the case. The command
  25         below can be useful for inspecting header-file changes since
  26         the last release X.Y:
  27
  28                 git diff X.Y..HEAD -- lib/notmuch.h
  29
  30         Note: We currently don't plan to increment
  31         LIBNOTMUCH_VERSION_MAJOR beyond 1, so if there *are*
  32         incompatible changes to the library interface, then
  33         stop. Don't release. Figure out the plan on the notmuch
  34         mailing list.
  35
  36         Commit this change, if any.
  37
  38 3) Create an entry for the new release in debian/changelog
  39
  40         The syntax of this file is tightly restricted, but the
  41         available emacs mode (see the dpkg-dev-el package helps).  The
  42         entries here will be the Debian-relevant single-line
  43         description of changes from the NEWS entry. And the version
  44         must match the version in the next step.
  45
  46         Commit this change.
  47
  48         XXX: It would be great if this step were automated as part of
  49         release, (taking entries from NEWS and the version from the
  50         VERSION, and creating a new commit).
  51
  52 4) Run "make VERSION=X.Y release" which will perform the following steps:
  53
  54    For the X.Y version, we'll generally just increment Y. But for
  55    major milestones of usability we're increment X as well.
  56
  57         * Ensure that the caller passed VERSION=X.Y
  58         * Verify that the source tree is clean
  59         * Compile the current notmuch code (aborting release if it fails)
  60         * Run the notmuch test suite (aborting release if it fails)
  61         * Generate the final tar file
  62         * Generate a .sha1 sum file for the tar file
  63         * Sign the sha1sum using your GPG setup (asks for your GPG password)
  64         * Check that no release exists with the current version
  65         * scp the three files to appear on http://notmuchmail.org/releases
  66         * Create a LATEST-notmuch-version file (after deleting any old one)
  67         * Place local copies of the three files in the releases directory
  68         * Tag the entire source tree with a tag of the form X.Y.Z, and sign
  69           the tag with your GPG key (asks for your GPG password, and you
  70           may need to set GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL to match
  71           your public-key's setting or this fails.)
  72         * Push that tag
  73         * Provide some text for the release announcement (see below).
  74
  75 5) Send a message to notmuch@notmuchmail.org to announce the release.
  76
  77         Use the text provided from "make release" above, (if for some
  78         reason you lose this message, "make release-message" prints
  79         it again for you.