tests: enhance AT_SYNCLINES_COMPILE.

[bison.git] / HACKING

diff --git a/HACKING b/HACKING
index 062952cc4d074a69de9c05c585a9ea526f5ca04a..0cdabf9c341c8e3adc761747f179737e37bee5c5 100644 (file)
--- a/HACKING
+++ b/HACKING
@@ -197,11 +197,17 @@ release:
   that it does not make sense for glr.c, which should be ANSI,
   but currently is actually GNU C, nor for lalr1.cc.
 
+- Test with a very recent version of GCC for both C and C++.  Testing
+  with older versions that are still in use is nice too.
+
 
 * Release Procedure
 
-** Try to get the *.pot files to the Translation Project at least one week
-before a stable release, to give them time to translate them.
+** Try to get the *.pot files to the Translation Project at least one
+week before a stable release, to give them time to translate them.
+Before generating the *.pot files, make sure that po/POTFILES.in and
+runtime-po/POTFILES.in list all files with translatable strings.
+This helps: grep -l '\<_(' *
 
 ** Tests
 See above.
@@ -213,9 +219,17 @@ causes it to be rejected by recent Gettext releases; please report
 these to the Translation Project.
 
 ** Update README
-Make sure the information in this file is current.  Most notably, make sure it
-recommends a version of GNU M4 that is compatible with the latest Bison
-sources.
+Make sure the information in README is current.  Most notably, make sure
+it recommends a version of GNU M4 that is compatible with the latest
+Bison sources.
+
+** Check copyright years.
+We update years in copyright statements throughout Bison once at the
+start of every year by running `make update-copyright'.  However, before
+a release, it's good to verify that it's actually been run.  Besides the
+copyright statement for each Bison file, check the copyright statements
+that the skeletons insert into generated parsers, and check all
+occurrences of PACKAGE_COPYRIGHT_YEAR in configure.ac.
 
 ** Update NEWS
 The version number, *and* the date of the release (including for
@@ -224,9 +238,6 @@ betas).
 ** Update ChangeLog
 Should have an entry similar to `Version 1.49b.'.
 
-** Update configure.ac
-Be sure PACKAGE_COPYRIGHT_YEAR is up-to-date.
-
 ** Tag the release
 Before Bison will build with the right version number, you must tag the release
 in git.  Do this after all other changes.  The command is similar to:
@@ -237,12 +248,6 @@ The log message can be simply:
 
   Bison 2.3b
 
-** make distcheck
-Be sure to use automake 1.10.3, 1.11.1, or later in order to avoid the
-security issue described here:
-
-  http://thread.gmane.org/gmane.comp.sysutils.autotools.announce/131
-
 ** Push
 Once `make distcheck' passes, push your changes and the tag.
 `git push' without arguments will not push the tag.
@@ -338,9 +343,10 @@ To generate a template announcement file:
 
   make RELEASE_TYPE=alpha gpg_key_ID=F125BDF3 announcement
 
-where alpha can be replaced by beta or major and F125BDF3 should be replaced
-with your key ID.  For an example of how to fill out the template, search the
-mailing list archives for the most recent release announcement.
+where alpha can be replaced by beta or stable and F125BDF3 should be
+replaced with your key ID.  For an example of how to fill out the
+template, search the mailing list archives for the most recent release
+announcement.
 
 Complete/fix the announcement file, and send it at least to
 info-gnu@gnu.org (if a real release, or a ``serious beta''),