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, please 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 _in a non-upwardly compatible_ way, but do check
  25         that that is the case. The command below can be useful for
  26         inspecting header-file changes since the last release X.Y:
  27
  28                 git diff X.Y..HEAD -- lib/notmuch.h
  29
  30         Commit this change, if any.
  31
  32 3) Update the debian/libnotmuchX.symbols file
  33
  34         If the library version changed at all (step 2) it probably
  35         means that symbols have changed/been added, in which case the
  36         debian symbols file also needs to be updated:
  37
  38                dpkg-buildpackage -uc -us
  39                dpkg-gensymbols -plibnotmuchX | patch -p0
  40
  41         Carefully review the changes to debian/libnotmuch1.symbols to
  42         make sure there are no unexpected changes.  Remove any debian
  43         versions from symbols.
  44
  45         Commit this change, if any.
  46
  47 4) Upgrade the version in the file "version"
  48
  49         The scheme for the release number is as follows:
  50
  51         A major milestone in usability causes an increase in the major
  52         number, yielding a two-component version with a minor number
  53         of 0, (such as "1.0" or "2.0").
  54
  55         Otherwise, releases with changes in features cause an increase
  56         in the minor number, yielding a two-component version, (such
  57         as "1.1" or "1.2").
  58
  59         Finally, releases that do not change "features" but are merely
  60         bug fixes either increase the micro number or add it (starting
  61         at ".1" if not present). So a bug-fix release from "1.0" would
  62         be "1.0.1" and a subsequent bug-fix release would be "1.0.2"
  63         etc.
  64
  65         When you are happy with the file 'version', run
  66
  67              make update-versions
  68
  69         to propagate the version to the other places needed.
  70
  71         Commit these changes.
  72
  73 5) Create an entry for the new release in debian/changelog
  74
  75         The syntax of this file is tightly restricted, but the
  76         available emacs mode (see the dpkg-dev-el package) helps.
  77         The entries here will be the Debian-relevant single-line
  78         description of changes from the NEWS entry. And the version
  79         must match the version in the next step.
  80
  81         Commit this change.
  82
  83         XXX: It would be great if this step were automated as part of
  84         release, (taking entries from NEWS and the version from the
  85         version file, and creating a new commit, etc.)
  86
  87 6) Run "make release" which will perform the following steps.
  88
  89    Note: in order to really upload anything, set the make variable
  90    REALLY_UPLOAD=yes
  91
  92         * Ensure that the version consists only of digits and periods
  93         * Ensure that version and debian/changelog have the same version
  94         * Verify that the source tree is clean
  95         * Compile the current notmuch code (aborting release if it fails)
  96         * Run the notmuch test suite (aborting release if it fails)
  97         * Check that no release exists with the current version
  98         * Make a signed tag
  99         * Generate a tar file from this tag
 100         * Generate a .sha1 sum file for the tar file and GPG sign it.
 101         * Commit a (delta for a) copy of the tar file using pristine-tar
 102         * Tag for the debian version
 103         * if REALLY_UPLOAD=yes
 104           - push the signed tag to the origin
 105             XXX FIXME push debian tag
 106           - scp tarball to web site
 107         * Provide some text for the release announcement (see below).
 108
 109 7) Send a message to notmuch@notmuchmail.org to announce the release.
 110
 111         Use the text provided from "make release" above, (if for some
 112         reason you lose this message, "make release-message" prints
 113         it again for you.