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.
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
** 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:
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''),