]> git.cworth.org Git - notmuch/blob - RELEASING
Avoid segmentation fault with NOTMUCH_CONFIG=/new/config/file notmuch setup
[notmuch] / 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) Upgrade the version in the file "version"
39
40         The scheme for the release number is as follows:
41
42         A major milestone in usability causes an increase in the major
43         number, yielding a two-component version with a minor number
44         of 0, (such as "1.0" or "2.0").
45
46         Otherwise, releases with changes in features cause an increase
47         in the minor number, yielding a two-component version, (such
48         as "1.1" or "1.2").
49
50         Finally, releases that do not change "features" but are merely
51         bug fixes either add increase the micro number or add it
52         (starting at ".1" if not present). So a bug-fix release from
53         "1.0" would be "1.0.1" and a subsequent bug-fix release would
54         be "1.0.2" etc.
55
56         Commit this change.
57
58 4) Create an entry for the new release in debian/changelog
59
60         The syntax of this file is tightly restricted, but the
61         available emacs mode (see the dpkg-dev-el package) helps.
62         The entries here will be the Debian-relevant single-line
63         description of changes from the NEWS entry. And the version
64         must match the version in the next step.
65
66         Commit this change.
67
68         XXX: It would be great if this step were automated as part of
69         release, (taking entries from NEWS and the version from the
70         version file, and creating a new commit, etc.)
71
72 5) Run "make release" which will perform the following steps.
73
74    Note: If any problem occurs during the process, (such as a lintian
75    warning that you decide should be fixed), you can abort at the
76    prompt for your GPG passphrase and nothing will have been uploaded
77    yet.
78
79         * Ensure that the version consists only of digits and periods
80         * Ensure that version and debian/changelog have the same version
81         * Verify that the source tree is clean
82         * Compile the current notmuch code (aborting release if it fails)
83         * Run the notmuch test suite (aborting release if it fails)
84         * Compile a Debian package
85         * Copy the tar file from what was made for Debian package
86         * Generate a .sha1 sum file for the tar file
87         * Sign the sha1sum using your GPG setup (asks for your GPG password)
88         * Check that no release exists with the current version
89         * scp the three files to appear on http://notmuchmail.org/releases
90         * Create a LATEST-notmuch-version file (after deleting any old one)
91         * Place local copies of the tar, sha1, and gpg files into releases
92         * Upload the Debian package
93         * Place a local copy of the Debian package files in releases
94         * Tag the entire source tree with a tag of the form X.Y.Z, and sign
95           the tag with your GPG key (asks for your GPG password, and you
96           may need to set GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL to match
97           your public-key's setting or this fails.)
98         * Push that tag
99         * Provide some text for the release announcement (see below).
100
101 6) Send a message to notmuch@notmuchmail.org to announce the release.
102
103         Use the text provided from "make release" above, (if for some
104         reason you lose this message, "make release-message" prints
105         it again for you.