X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/e141f4d4bb6584bfbf13003047a2e48e9a6eab6a..c826013fb38c98861ef0fc5d4dc3fb3fb4f555be:/HACKING?ds=inline diff --git a/HACKING b/HACKING index 062952cc..0cdabf9c 100644 --- 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''),