1 Here are the steps to follow to create a new notmuch release.
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.
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:
12 1) Verify that the NEWS file is up to date.
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).
19 2) Verify that the library version in lib/Makefile.local is correct
21 See the instructions there for how to increment it.
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:
28 git diff X.Y..HEAD -- lib/notmuch.h
30 Commit this change, if any.
32 3) Update the debian/libnotmuchX.symbols file
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:
38 dpkg-buildpackage -uc -us
39 dpkg-gensymbols -plibnotmuchX | patch -p0
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.
45 Commit this change, if any.
47 4) Upgrade the version in the file "version"
49 The scheme for the release number is as follows:
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").
55 Otherwise, releases with changes in features cause an increase
56 in the minor number, yielding a two-component version, (such
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"
67 5) Create an entry for the new release in debian/changelog
69 The syntax of this file is tightly restricted, but the
70 available emacs mode (see the dpkg-dev-el package) helps.
71 The entries here will be the Debian-relevant single-line
72 description of changes from the NEWS entry. And the version
73 must match the version in the next step.
77 XXX: It would be great if this step were automated as part of
78 release, (taking entries from NEWS and the version from the
79 version file, and creating a new commit, etc.)
81 6) Run "make release" which will perform the following steps.
83 Note: If any problem occurs during the process, (such as a lintian
84 warning that you decide should be fixed), you can abort at the
85 prompt for your GPG passphrase and nothing will have been uploaded
88 * Ensure that the version consists only of digits and periods
89 * Ensure that version and debian/changelog have the same version
90 * Verify that the source tree is clean
91 * Compile the current notmuch code (aborting release if it fails)
92 * Run the notmuch test suite (aborting release if it fails)
93 * Compile a Debian package
94 * Copy the tar file from what was made for Debian package
95 * Generate a .sha1 sum file for the tar file
96 * Sign the sha1sum using your GPG setup (asks for your GPG password)
97 * Check that no release exists with the current version
98 * scp the three files to appear on http://notmuchmail.org/releases
99 * Create a LATEST-notmuch-version file (after deleting any old one)
100 * Place local copies of the tar, sha1, and gpg files into releases
101 * Upload the Debian package
102 * Place a local copy of the Debian package files in releases
103 * Tag the entire source tree with a tag of the form X.Y.Z, and sign
104 the tag with your GPG key (asks for your GPG password, and you
105 may need to set GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL to match
106 your public-key's setting or this fails.)
108 * Provide some text for the release announcement (see below).
110 7) Send a message to notmuch@notmuchmail.org to announce the release.
112 Use the text provided from "make release" above, (if for some
113 reason you lose this message, "make release-message" prints