hacking: update advice w.r.t. release process
[platform/upstream/automake.git] / HACKING
diff --git a/HACKING b/HACKING
index 87318fd..84440a3 100644 (file)
--- a/HACKING
+++ b/HACKING
 = Naming
 
 * We've adopted the convention that internal AC_SUBSTs should be
-  named with a leading `am__', and internally generated targets
-  should be named with a leading `am--'.  This convention, although
+  named with a leading 'am__', and internally generated targets
+  should be named with a leading 'am--'.  This convention, although
   in place from at least February 2001, isn't yet universally used.
   But all new code should use it.
 
-  We used to use `_am_' as the prefix for an internal AC_SUBST.
+  We used to use '_am_' as the prefix for an internal AC_SUBST.
   However, it turns out that NEWS-OS 4.2R complains if a Makefile
-  variable begins with `_'.  Yay for them.  I changed the target
-  naming convention just to be safe.
+  variable begins with the underscore character.  Yay for them.
+  I changed the target naming convention just to be safe.
 
 ================================================================
-= Editing `.am' files
+= Editing '.am' files
 
 * Always use $(...) and not ${...}
 
-* Use `:', not `true'.  Use `exit 1', not `false'.
+* Use ':', not 'true'.  Use 'exit 1', not 'false'.
 
-* Use `##' comments liberally.  Comment anything even remotely
+* Use '##' comments liberally.  Comment anything even remotely
   unusual.
 
 * Never use basename or dirname.  Instead use sed.
 
-* Do not use `cd' within back-quotes, use `$(am__cd)' instead.
+* Do not use 'cd' within back-quotes, use '$(am__cd)' instead.
   Otherwise the directory name may be printed, depending on CDPATH.
-  More generally, do not ever use plain `cd' together with a relative
+  More generally, do not ever use plain 'cd' together with a relative
   directory that does not start with a dot, or you might end up in one
   computed with CDPATH.
 
 = Working with git
 
 * To regenerate dependent files created by aclocal and automake,
-  use the `bootstrap' script.  It uses the code from the source
+  use the 'bootstrap' script.  It uses the code from the source
   tree, so the resulting files (aclocal.m4 and Makefile.in) should
   be the same as you would get if you install this version of
   automake and use it to generate those files.  Be sure to have the
   latest stable version of Autoconf installed.  If such version is
   not installed as "autoconf", pass it explicitly (along with the
-  accompanying "autom4te") when calling `bootstrap' and `configure'.
+  accompanying "autom4te") when calling 'bootstrap' and 'configure'.
   For example:
     $ AUTOCONF=autoconf2.68 AUTOM4TE=autom4te2.68 ./bootstrap
     $ ./configure AUTOCONF=autoconf2.68 AUTOM4TE=autom4te2.68
 
 * Make sure each test file is executable.
 
-* Use `keep_testdirs=yes' to keep test directories for successful
-  tests also.
+* Export the 'keep_testdirs' environment variable to "yes" to keep
+  test directories for successful tests also.
 
 * Use perl coverage information to ensure your new code is thoroughly
   tested by your new tests.
 
-* See file `tests/README' for more information.
+* See file 'tests/README' for more information.
 
 ================================================================
 = Release procedure
 
 * Fetch new versions of the files that are maintained by the FSF.
   Commit.  Unfortunately you need an FSF account to do this.
-  (You can also use `make fetch', but that is still woefully incomplete.)
+  (You can also use "make fetch", but that is still woefully incomplete.)
 
 * Update NEWS.
 
 * Run this:
   ./bootstrap && ./configure && make && make check && make distcheck
 
-* Run `make git-release'.
-  This will run "make dist" to create the tarballs, commit the last
-  changes to NEWS, configure.ac and m4/amversion.m4, tag the repository,
-  sign the tarballs, and upload them.
-  Use `make GNUPLOADFLAGS="--user key" git-release' to sign with
-  a non-default key.
+* Run "make git-tag-release".
+  This will run the maintainer checks, check that the NEWS file is
+  up-to-date, check that the local git repository and working tree
+  are clean and up-to-date, and create a proper signed git tag for
+  the release (based on the contents of $(VERSION)).
+
+* Run "make git-upload-release".
+  This will first verify that you are releasing from a tagged version
+  and that the local git repository and working tree are clean and
+  up-to-date, and will then run "make dist" to create the tarballs,
+  and invoke the 'gnupload' script sign and upload them to the correct
+  locations.  In case you need to sign with a non-default key, you can
+  use "make GNUPLOADFLAGS='--user KEY' git-upload-release".
 
 * Update version number in configure.ac to next alpha number.
   Re-run ./bootstrap and commit.
 
-* Don't forget to `git push' your changes so they appear in the public
+* Don't forget to "git push" your changes so they appear in the public
   git tree.
 
 * For stable releases, update the manuals at www.gnu.org: