]> git.saurik.com Git - bison.git/blobdiff - HACKING
tests: enhance AT_SYNCLINES_COMPILE.
[bison.git] / HACKING
diff --git a/HACKING b/HACKING
index 82f07bb4f32fb11b91fbd886b8c88488cbb9f519..0cdabf9c341c8e3adc761747f179737e37bee5c5 100644 (file)
--- a/HACKING
+++ b/HACKING
@@ -172,6 +172,9 @@ release:
   that 1. Bison compiles cleanly, 2. the parsers it produces compile
   cleanly too.
 
+- Build with -DGNULIB_POSIXCHECK.  It suggests gnulib modules that can
+  fix portability issues.
+
 - run `make maintainer-check' which:
   - runs `valgrind -q bison' to run Bison under Valgrind.
   - runs the parsers under Valgrind.
@@ -194,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.
@@ -210,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
@@ -221,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:
@@ -329,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''),
@@ -354,8 +369,7 @@ Push these changes.
 
 -----
 
-Copyright (C) 2002, 2003, 2004, 2005, 2007, 2008, 2009
-Free Software Foundation, Inc.
+Copyright (C) 2002-2005, 2007-2010 Free Software Foundation, Inc.
 
 This file is part of GNU Bison.