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
+ not mentioned there. If so, please 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
Commit this change, if any.
-3) Run "make VERSION=X.Y release" which will perform the following steps:
+3) Upgrade the version in the file "version"
- For the X.Y version, we'll generally just increment Y. But for
- major milestones of usability we're increment X as well.
+ The scheme for the release number is as follows:
- * Ensure that the caller passed VERSION=X.Y
+ 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 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.
+
+ Note: If any problem occurs during the process, (such as a lintian
+ warning that you decide should be fixed), you can abort at the
+ prompt for your GPG passphrase and nothing will have been uploaded
+ yet.
+
+ * Ensure that the version consists only of digits and periods
+ * Ensure that version and debian/changelog have the same version
* 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
+ * Compile a Debian package
+ * Copy the tar file from what was made for Debian package
* 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
+ * Place local copies of the tar, sha1, and gpg files into releases
+ * Upload the Debian package
+ * Place a local copy of the Debian package files in releases
* 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
* Push that tag
* Provide some text for the release announcement (see below).
-4) Send a message to notmuch@notmuchmail.org to announce the release.
+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
projects / notmuch / blobdiff