X-Git-Url: https://git.notmuchmail.org/git?p=notmuch;a=blobdiff_plain;f=RELEASING;h=6c714f8e48a691ab8ae32fd7ecd22c3e71f52439;hp=99c6d79ecb86812471fab6adefe795ce42ace68a;hb=483f422699cc480b856ceeac77a4fa5d11f82ea0;hpb=ac3dcac7e6d18b787fc65d02a3aa8db3eba805b4 diff --git a/RELEASING b/RELEASING index 99c6d79e..6c714f8e 100644 --- a/RELEASING +++ b/RELEASING @@ -35,11 +35,31 @@ repository. From here, there are just a few steps to release: Commit this change, if any. -3) Create an entry for the new release in debian/changelog +3) Upgrade the version in the file "version" + + The scheme for the release number is as follows: + + 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 + 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. @@ -47,24 +67,30 @@ repository. From here, there are just a few steps to release: XXX: It would be great if this step were automated as part of release, (taking entries from NEWS and the version from the - VERSION, and creating a new commit). + version file, and creating a new commit, etc.) -4) Run "make VERSION=X.Y release" which will perform the following steps: +5) Run "make release" which will perform the following steps. - For the X.Y version, we'll generally just increment Y. But for - major milestones of usability we're increment X as well. + 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 caller passed VERSION=X.Y + * 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 @@ -72,7 +98,7 @@ repository. From here, there are just a few steps to release: * Push that tag * Provide some text for the release announcement (see below). -5) 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