X-Git-Url: https://git.notmuchmail.org/git?p=notmuch;a=blobdiff_plain;f=RELEASING;h=88dab04eefd5dcc9ca78f9b76ee71ecf96215d7e;hp=70a2ec547d2653379c476c99bc9dbd54173a7c07;hb=baa2c9721d850ea95857f44ba0b44147c80f7998;hpb=80240877f836214e556f1ff75a058465a69f2dea diff --git a/RELEASING b/RELEASING index 70a2ec54..88dab04e 100644 --- a/RELEASING +++ b/RELEASING @@ -13,7 +13,7 @@ repository. From here, there are just a few steps to release: 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 @@ -21,21 +21,30 @@ repository. From here, there are just a few steps to release: See the instructions there for how to increment it. The version should have been updated with any commits that - added API, but do check that that is the case. The command - below can be useful for inspecting header-file changes since - the last release X.Y: + added API _in a non-upwardly compatible_ way, but do check + that that is the case. The command below can be useful for + inspecting header-file changes since the last release X.Y: git diff X.Y..HEAD -- lib/notmuch.h - Note: We currently don't plan to increment - LIBNOTMUCH_VERSION_MAJOR beyond 1, so if there *are* - incompatible changes to the library interface, then - stop. Don't release. Figure out the plan on the notmuch - mailing list. + Commit this change, if any. + +3) Update the debian/libnotmuchX.symbols file + + If the library version changed at all (step 2) it probably + means that symbols have changed/been added, in which case the + debian symbols file also needs to be updated: + + dpkg-buildpackage -uc -us + dpkg-gensymbols -plibnotmuchX | patch -p0 + + Carefully review the changes to debian/libnotmuch1.symbols to + make sure there are no unexpected changes. Remove any debian + versions from symbols. Commit this change, if any. -3) Upgrade the version in the file "version" +4) Upgrade the version in the file "version" The scheme for the release number is as follows: @@ -48,18 +57,24 @@ repository. From here, there are just a few steps to release: as "1.1" or "1.2"). Finally, releases that do not change "features" but are merely - bug fixes either add 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. + 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. + When you are happy with the file 'version', run + + make update-versions + + to propagate the version to the other places needed. -4) Create an entry for the new release in debian/changelog + Commit these changes. + +5) 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. @@ -69,28 +84,29 @@ repository. From here, there are just a few steps to release: 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: +6) Run "make release" which will perform the following steps. + + Note: in order to really upload anything, set the make variable + REALLY_UPLOAD=yes * 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 - * 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 - * 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 - your public-key's setting or this fails.) - * Push that tag + * Make a signed tag + * Generate a tar file from this tag + * Generate a .sha1 sum file for the tar file and GPG sign it. + * Commit a (delta for a) copy of the tar file using pristine-tar + * Tag for the debian version + * if REALLY_UPLOAD=yes + - push the signed tag to the origin + XXX FIXME push debian tag + - scp tarball to web site * Provide some text for the release announcement (see below). -6) Send a message to notmuch@notmuchmail.org to announce the release. +7) 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