RELEASING: Change wording of libnotmuch version instruction
authorCarl Worth <cworth@cworth.org>
Fri, 16 Apr 2010 03:50:46 +0000 (20:50 -0700)
committerCarl Worth <cworth@cworth.org>
Fri, 16 Apr 2010 03:50:46 +0000 (20:50 -0700)
We actually want this version to be incremented by the commits that
extend the interface. So the release process really is not to just
verify two things (NEWS and libnotmuch version), then run "make
VERSION=x.y release", and send the mail. Quite nice.

RELEASING

index f47ba39c520b7d0272a2044d72c94361019a9566..fbee322a59bf7a63e0c6f046d9f297b1d04ee329 100644 (file)
--- a/RELEASING
+++ b/RELEASING
@@ -16,13 +16,16 @@ repository. From here, there are just a few steps to release:
        not mentioned there. If so, pleas add them, (and ask the
        authors of the commits to update NEWS in the future).
 
-2) Increment the libnotmuch library version in lib/Makefile.local
+2) Verify that the library version in lib/Makefile.local is correct
 
-       See the instructions there for how to increment it. The
-       command below can be useful for inspecting header-file changes
-       since the last release X.Y.Z:
+       See the instructions there for how to increment it.
 
-               git diff X.Y.Z..HEAD -- lib/notmuch.h
+       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:
+
+               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*
@@ -30,7 +33,7 @@ repository. From here, there are just a few steps to release:
        stop. Don't release. Figure out the plan on the notmuch
        mailing list.
 
-       Commit this change.
+       Commit this change, if any.
 
 3) Run "make VERSION=X.Y release" which will perform the following steps: