+ 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.
+
+ 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.
+
+ 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 version consists only of digits and periods
+ * Ensure that version and debian/changelog have the same version