]> git.notmuchmail.org Git - notmuch/blobdiff - RELEASING
Fix double free in guess_from_received_header().
[notmuch] / RELEASING
index d314a6c68a3f63c87a8c1e3a488910618eb0a561..475100a6dd00af9c0ff04daa6c28cc01e75f6344 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
-       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
@@ -35,7 +35,21 @@ repository. From here, there are just a few steps to release:
 
        Commit this change, if any.
 
-3) Upgrade the version in the file "version"
+3) Update the debian/libnotmuch1.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 -plibnotmuch1 | patch -p0
+
+       Carefully review the changes to debian/libnotmuch1.symbols to
+       make sure there are no unexpected changes.
+
+       Commit this change, if any.
+
+4) Upgrade the version in the file "version"
 
        The scheme for the release number is as follows:
 
@@ -48,18 +62,18 @@ 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.
 
-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
-       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,7 +83,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.)
 
-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
@@ -98,7 +112,7 @@ repository. From here, there are just a few steps to release:
        * 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