X-Git-Url: https://git.notmuchmail.org/git?p=notmuch;a=blobdiff_plain;f=RELEASING;h=d314a6c68a3f63c87a8c1e3a488910618eb0a561;hp=f47ba39c520b7d0272a2044d72c94361019a9566;hb=e6d20b7b8f47bcd5da14639c31a4943e188c070d;hpb=00263dd1a9e08ab1fa947fa58d1c2ad62e8b9653

diff --git a/RELEASING b/RELEASING
index f47ba39c..d314a6c6 100644
--- 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,24 +33,64 @@ 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, if any.
+
+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 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.
+
+	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
+	description of changes from the NEWS entry. And the version
+	must match the version in the next step.
+
 	Commit this change.
 
-3) Run "make VERSION=X.Y release" which will perform the following steps:
+	XXX: It would be great if this step were automated as part of
+	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.
 
-   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
@@ -55,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).
 
-4) 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