the appropriate paperwork. Second, be sure to add their name and
email address to THANKS.
-** If a change fixes a test, mention the test in the ChangeLog entry.
+** If a change fixes a test, mention the test in the commit message.
** Bug reports
-If somebody reports a new bug, mention his name in the ChangeLog entry
+If somebody reports a new bug, mention his name in the commit message
and in the test case you write. Put him into THANKS.
The correct response to most actual bugs is to write a new test case
which demonstrates the bug. Then fix the bug, re-run the test suite,
and check everything in.
-** You may find it useful to install the git-merge-changelog merge driver:
-
- http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c
-
-When following the generic installation instructions there, keep in mind that
-your clone of Bison's git repository already contains appropriate
-.gitattributes files, and running Bison's bootstrap script will make the
-necessary changes to .git/config.
-
* Hacking
$ git checkin ...
+For a suggestion of what gnulib commit might be stable enough for a
+formal release, see the ChangeLog in the latest gnulib snapshot at:
+
+ http://erislabs.net/ianb/projects/gnulib/
+
+The autoconf files we use are currently:
+
+ m4/m4.m4
+ lib/m4sugar/m4sugar.m4
+ lib/m4sugar/foreach.m4
+
+These files don't change very often in Autoconf, so it should be
+relatively straight-forward to examine the differences in order to
+decide whether to update.
* Test suite
- Build with -DGNULIB_POSIXCHECK. It suggests gnulib modules that can
fix portability issues.
+- Check with `make syntax-check' if there are issues diagnosed by
+ gnulib.
+
- run `make maintainer-check' which:
- runs `valgrind -q bison' to run Bison under Valgrind.
- runs the parsers under Valgrind.
Bison's included XSLT style sheets with the output of --report=all and
--graph.
+- running `make maintainer-release-check' takes care of running
+ maintainer-check, maintainer-push-check and maintainer-xml-check.
+
- Change tests/atlocal/CFLAGS to add your preferred options. For
instance, `-traditional' to check that the parsers are K&R. Note
that it does not make sense for glr.c, which should be ANSI,
* Release Procedure
+** Update the submodules. See above.
+
+** Update maintainer tools, such as Autoconf. See above.
+
** 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
The version number, *and* the date of the release (including for
betas).
-** Update ChangeLog
-Should have an entry similar to `Version 1.49b.'.
+** Mention the release name in a commit message
+Should have an entry similar to `Version 2.3b.'.
** 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:
+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:
git tag -a v2.3b
-The log message can be simply:
+The commit message can be simply:
Bison 2.3b
*** put bison-2.3b.tar.gz # This can take a while.
*** put bison-2.3b.tar.gz.sig
*** put bison-2.3b.tar.gz.directive.asc
-*** Repeat all these steps for bison-2.3b.tar.bz2.
+*** Repeat all these steps for bison-2.3b.tar.xz.
** Update Bison manual on www.gnu.org.
-----
-Copyright (C) 2002, 2003, 2004, 2005, 2007, 2008, 2009, 2010 Free
-Software Foundation, Inc.
+Copyright (C) 2002-2005, 2007-2012 Free Software Foundation, Inc.
This file is part of GNU Bison.
projects / bison.git / blobdiff