]> git.notmuchmail.org Git - notmuch/blobdiff - RELEASING
RELEASING: update discussion of version handling
[notmuch] / RELEASING
index d314a6c68a3f63c87a8c1e3a488910618eb0a561..2cec3807dfaf80708992f3abac349baf197bdfd9 100644 (file)
--- 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
 
        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
        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
        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
 
 
                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.
 
 
        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:
 
 
        The scheme for the release number is as follows:
 
@@ -48,18 +57,22 @@ 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
        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.
+       Update bindings/python/notmuch/version.py to match version.
+
+       Update the version in notmuch.1 to match version.
+
+       Commit these changes.
 
 
-4) Create an entry for the new release in debian/changelog
+5) Create an entry for the new release in debian/changelog
 
        The syntax of this file is tightly restricted, but the
 
        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.
 
        description of changes from the NEWS entry. And the version
        must match the version in the next step.
 
@@ -69,7 +82,7 @@ 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.)
 
        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: If any problem occurs during the process, (such as a lintian
    warning that you decide should be fixed), you can abort at the
 
    Note: If any problem occurs during the process, (such as a lintian
    warning that you decide should be fixed), you can abort at the
@@ -98,7 +111,7 @@ repository. From here, there are just a few steps to release:
        * Push that tag
        * Provide some text for the release announcement (see below).
 
        * Push that tag
        * 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
 
        Use the text provided from "make release" above, (if for some
        reason you lose this message, "make release-message" prints