1 ============================================================================
4 * This file attempts to describe the conventions to use when hacking automake.
6 * After git checkout from Savannah, you can do an initial build with, e.g.:
7 ./bootstrap && ./configure --prefix=/tmp/amdev && make
9 ============================================================================
12 * The correct response to most actual bugs is to write a new test case
13 which demonstrates the bug. Then fix the bug, rerun the test suite,
14 and check everything in. Run the test suite in parallel or it takes ages.
16 * If you incorporate a change from somebody on the net:
17 - First, if it is not a tiny change, you must make sure they have
18 signed the appropriate paperwork.
19 - Second, add their name and email address to THANKS.
21 * If a change fixes or adds a test, mention the test in the commit
22 message. If a change fixes a bug registered in the Automake debbugs
23 tracker, mention the bug number in the commit message, using
24 the short url form, like https://bugs.gnu.org/1234. See section below
25 about commit messages.
27 * If a person or people report a new bug, mention their name(s) in the
28 commit message that fixes or exposes the bug, and add a line for them
31 * When documenting a non-trivial idiom or example in the manual, be
32 sure to add a test case for it, and to reference such test case from
33 a proper Texinfo comment.
35 * Some files in the automake package are not owned by automake (many
36 by gnulib, https://gnu.org/s/gnulib); these files are listed in the
37 $(FETCHFILES) variable in maintainer/maint.mk. They should never be
38 edited here. All but two of them can be updated from respective
39 upstreams with "make fetch" (this should be done especially before
40 releases). The only exceptions are help2man (install the current
41 version and copy in by hand) and 'lib/COPYING' (from FSF), which
42 should be updated by hand whenever the GPL gets updated (which
43 shouldn't happen that often anyway :-).
45 Conversely, automake holds the master copy of a number of files that
46 are copied into other projects, such as install-sh, mdate-sh,
47 Channels.pm and ChannelDefs.pm, and plenty more; grep for bug-automake
48 in lib/* for most of the scripts, and see <gnulib>/config/srclist.txt
49 and <autoconf>/build-aux/fetch.pl for lists of such files on two
50 notable receiving ends. Do your best not to break them.
52 * All changes from the last release that are not trivial bug fixes should
55 * Changes which are potentially controversial, require a non-trivial
56 plan, or must be implemented gradually with a roadmap spanning several
57 releases (either minor or major) should be discussed on the list,
58 and have a proper entry in the PLANS directory. This entry should be
59 always committed in the "maint" branch, even if the change it deals
60 with is only for the master branch, or a topic branch. Usually, in
61 addition to this, it is useful to open a "wishlist" report on the
62 Automake debbugs tracker, to keep the idea more visible, and have the
63 discussions surrounding it easily archived in a central place.
65 ===========================================================================
66 = Setting the development environment
68 * In development, ./GNUmakefile is used, not (the generated) ./Makefile.
69 Run make V=1 to see the commands that are run.
71 * The required and optional dependencies used by Automake and its test suite
72 can be automatically fetched using the GNU Guix package manager with the
75 guix environment automake --ad-hoc \
76 gettext help2man texinfo libtool flex bison dejagnu zip icedtea \
77 python gcc-toolchain gfortran pkg-config vala
79 For other environments, you'll need to install the equivalent.
81 * To run the bin/automake or bin/aclocal scripts in a checkout, it is
82 necessary to set PERL5LIB, as in:
83 am=/path/to/automake/checkout
84 env PERL5LIB=$am/lib $am/bin/automake --help
85 env PERL5LIB=$am/lib $am/bin/aclocal --help
87 * If you need to test different Python versions, pyenv is probably the
88 most convenient way at this writing. https://github.com/pyenv
90 ============================================================================
93 * Automake's convention is that internal AC_SUBSTs and make variables
94 should be named with a leading 'am__', and internally generated targets
95 should be named with a leading 'am--'. This convention, although in
96 place from at least February 2001, isn't yet universally used.
97 But all new code should use it.
99 We used to use '_am_' as the prefix for an internal AC_SUBSTs.
100 However, it turns out that NEWS-OS 4.2R complains if a Makefile
101 variable begins with the underscore character. Yay for them.
102 We changed the target naming convention just to be safe.
104 * If you'd like to read some general background on automake and the
105 other GNU autotools, you might try this not-too-long web page (not
106 affiliated with GNU):
107 https://www.linux.com/news/best-practices-autotools/
109 ============================================================================
110 = Editing '.am' files
112 * For variables, always use $(...) and not ${...}.
114 * Prefer ':' over 'true', mostly for consistency with existing code.
116 * Use '##' comments liberally. Comment anything even remotely unusual,
117 and even usual things, to help future readers of the code understand.
119 * Never use basename or dirname. Instead, use sed.
121 * Do not use 'cd' within backquotes, use '$(am__cd)' instead.
122 Otherwise the directory name may be printed, depending on CDPATH.
123 More generally, do not ever use plain 'cd' together with a relative
124 directory that does not start with a dot, or you might end up in one
125 computed with CDPATH.
127 * For install and uninstall rules, if a loop is required, it should be
128 silent. Then the body of the loop itself should print each "important"
129 command it runs. The printed commands should be preceded by a single
132 * Ensure install rules do not create any installation directory where
133 nothing is to be actually installed. See automake bug#11030.
135 ============================================================================
136 = Editing conventions
138 * Indent using GNU style. For historical reasons, the perl code
139 contains portions indented using Larry Wall's style (perl-mode's
140 default), and other portions using the GNU style (cperl-mode's
141 default). Write new code using GNU style.
143 * Don't use & for function calls, unless really required.
144 The use of & prevents prototypes from being checked; it's also
145 uncommon in modern Perl code.
146 (Perl prototypes are unlike function prototypes in other
147 languages, so understand what they do.)
150 - After and during editing, run make info for error checking, and make pdf
151 to catch TeX-only errors.
152 - After adding a new node, you can update the @detailmenu with
153 M-x texinfo-master-menu (not tested with current Emacs releases, but
154 hopefully it still works).
155 - You'll probably have already added it to the higher-level menu under
156 which the new node was added, since that's necessary to run "make info".
158 ============================================================================
159 = Automake versioning and compatibility scheme
161 * There are three kinds of automake releases:
163 - new major releases (e.g., 2.0, 5.0)
164 - new minor releases (e.g., 1.14, 2.1)
165 - micro a.k.a. "bug-fixing" releases (e.g., 1.13.2, 2.0.1, 3.5.17).
167 A new major release should have the major version number bumped, and
168 the minor and micro version numbers reset to zero. A new minor release
169 should have the major version number unchanged, the minor version number
170 bumped, and the micro version number reset to zero. Finally, a new
171 micro version should have the major and minor version numbers unchanged,
172 and the micro version number bumped by one.
174 For example, the first minor version after 1.13.2 will be 1.14; the
175 first bug-fixing version after 1.14 that will be 1.14.1; the first
176 new major version after all such releases will be 2.0; the first
177 bug-fixing version after 2.0 will be 2.0.1; and a further bug-fixing
178 version after 2.0.1 will be 2.0.2.
180 * Micro releases should be just bug-fixing releases; no new features
181 should be added, and ideally, only trivial bugs, recent regressions,
182 or documentation issues should be addressed by them. On the other
183 hand, it's OK to include testsuite work and even testsuite refactoring
184 in a micro version, since a regression there is not going to annoy or
185 inconvenience Automake users, but only the Automake developers.
187 * Minor releases can introduce new "safe" features, do non-trivial but
188 mostly safe code clean-ups, and even add new runtime warnings (rigorously
189 non-fatal). But they shouldn't include any backward incompatible change,
190 nor contain any potentially destabilizing refactoring or sweeping change,
191 nor introduce new features whose implementation might be liable to cause
192 bugs or regressions in existing code. However, it might be acceptable to
193 introduce very limited and localized backward-incompatibility, *only*
194 if that is necessary to fix non-trivial bugs, address serious performance
195 issues, or greatly enhance usability. But please, do this sparsely and
198 * Major releases can introduce backward incompatibility (albeit such
199 incompatibility should be announced well in advance, and a smooth
200 transition plan prepared for them), and try more risky and daring
201 refactorings and code cleanups. Still, backward incompatibility is
202 extremely undesirable and should be avoided at all costs.
204 * For more information, refer to the extensive discussion associated
205 with automake bug#13578.
207 ============================================================================
210 * To regenerate dependent files created by aclocal and automake,
211 use the 'bootstrap' script. It uses the code from the source
212 tree, so the resulting files (aclocal.m4 and Makefile.in) should
213 be the same as you would get if you install this version of
214 automake and use it to generate those files.
216 * To get a faithful and correct rebuild, run:
217 ./bootstrap && ./config.status --recheck && make clean all
219 * Usually, it is best to run against the latest stable versions of
220 Autoconf, Libtool, etc., since that is what most users will
221 do. However, sometimes it may be necessary to use the development
222 versions due to bugs fixed, etc. Whatever is first in PATH wins.
223 (Some background: https://bugs.gnu.org/11347)
225 * The Automake git tree currently carries three basic branches:
226 'master', 'next' and 'maint'. In practice, for quite a few years now,
227 as of this writing in 2023, we have been using only the master branch,
228 due to lack of time and desire to deal with anything but fixing bugs.
229 The branch information in the items below and above should thus be
230 taken with a large dose of salt.
232 * The 'master' branch is where the development of the next release
233 takes place. It should be kept in a stable, almost-releasable state,
234 to simplify testing and deploying of new minor version. Note that
235 this is not a hard rule, and such "stability" is not expected to be
236 absolute (emergency releases are cut from the 'maint' branch anyway).
238 * When planning a release a dedicated branch should be created and after
239 the release is done, the release branch is to be merged both into the
240 'master' branch and the 'maint' branch.
242 * Besides merges from release branches, the 'maint' branch can contain
243 fixes for regressions, trivial bugs, or documentation issues, that
244 will be part of an emergency regression-fixing or security releases.
245 As a consequence it should always be kept in a releasable state and no
246 "active" development should be done whatsoever.
248 * The 'next' branch is reserved for the development of the next major
249 release. Experimenting a little is OK here, but don't let the branch
250 grow too unstable; if you need to do exploratory programming or
251 over-arching change, you should use a dedicated topic branch, and
252 only merge that back once it is reasonably stable.
254 * The 'master' branch should be kept regularly merged into the 'next'
255 branch. It is advisable to merge only after a set of related
256 commits have been applied, to avoid introducing too much noise in
259 * There may be a number of longer-lived feature branches for new
260 developments. They should be based off of a common ancestor of all
261 active branches to which the feature should or might be merged later.
263 * When merging, prefer 'git merge --log' over plain 'git merge', so that
264 a later 'git log' gives an indication of which actual patches were
265 merged even when they don't appear early in the list.
267 * The 'master', 'maint' and 'next' branches should not be rewound,
268 i.e., should always fast-forward, except maybe for privacy issues.
269 For feature branches, the announcement for the branch should
270 document the rewinding policy.
271 If a topic branch is expected to be rewound, it is good practice to put
272 it in the 'experimental/*' namespace; for example, a rewindable branch
273 dealing with Vala support could be named like "experimental/vala-work".
275 * If you need to trivially fix a change after a commit, e.g., a typo in
276 the NEWS entry, edit the file and then:
277 git commit --amend --no-edit NEWS
278 git commit --amend --date="$(date -R)" # update date of commit
280 * If you want to just completely lose your local changes:
281 git fetch && git reset --hard origin && git checkout && git submodule update
282 (the submodule stuff is for gnulib).
284 * The preferred way to create a patch to mail around:
285 git format-patch --stdout -1 >/tmp/some-patch.diff
286 which can then be applied with:
289 ============================================================================
290 = Writing a good commit message
292 * Here is the general format that Automake's commit messages are expected
293 to follow. See the further points below for clarifications and minor
296 topic: brief description (this is the "summary line").
298 <reference to relevant bugs, if any>
300 Here goes a more detailed explanation of why the commit is needed,
301 and a general overview of what it does, and how. This section
302 should almost always be provided, possibly only with the exception
303 of obvious fixes or very trivial changes.
305 And if the detailed explanation is quite long or detailed, you can
306 want to break it in more paragraphs.
308 Then you can add references to relevant mailing list discussions
309 (if any), with proper links. But don't take this as an excuse for
310 writing incomplete commit messages! The "distilled" conclusions
311 reached in such discussions should have been placed in the
314 Finally, here you can thank people that motivated or helped the
315 change. So, thanks to John Doe for bringing up the issue, and to
316 J. Random Hacker for providing suggestions and testing the patch.
318 <detailed list of touched files>
320 * To choose the topic label, please review the previous commits in the
321 git log or the ChangeLog file from a release tarball. There are no
322 hard-and-fast rules; the aim is a usable description. So script
323 names, Makefile targets, and more are all viable. Some examples:
324 aclocal automake build cosmetics doc maint python release test ylwrap
326 * The <detailed list of touched files> should usually be provided (but
327 for short or trivial changes), and should follow the GNU guidelines
328 for ChangeLog entries (described explicitly in the GNU Coding
329 Standards); it might be something of this sort:
331 * some/file (func1): Improved frobnication.
332 (func2): Adjusted accordingly.
333 * another/file (foo, bar): Likewise.
334 * t/foo.sh: New test.
335 * t/list-of-tests.mk (handwritten_TESTS): Add it.
336 * doc/automake.texi (Some Node): Document it.
339 * If your commit fixes an automake bug registered in the tracker (say
340 numbered 1234), you should put the following line after the summary
343 Fixes automake bug https://bugs.gnu.org/1234.
345 * If your commit is just related to the given bug report, but does not
346 fix it, you might want to add a line like this instead:
348 Related to automake bug https://bugs.gnu.org/1234.
350 * When referring to older commits, use 'git describe' output as pointer.
351 But also try to identify the given commit by date and/or summary line
352 if possible. Examples:
354 Since yesterday's commit, v1.11-2019-g4d2bf42, ...
356 ... removed in commit 'v1.11-1674-g02e9072' of 2012-01-01,
357 "dist: ditch support for lzma"...
359 * If the commit is a tiny change that is exempt from copyright paperwork, the
360 commit message should contain a separate line after the detailed list of
361 touched files like the following:
363 Copyright-paperwork-exempt: yes
365 * Generally write the commit message in present tense.
367 ============================================================================
370 * See file 't/README' for more information.
372 * Use "make check" and "make maintainer-check" liberally. It is often
373 useful to set VERBOSE=1 for more reporting on what is being done.
375 * Export the 'keep_testdirs' environment variable to "yes" to keep
376 *.dir test directories for successful tests also.
378 * Use Perl coverage information to ensure your new code is thoroughly
379 tested by your new tests.
381 * To run the tests, you should install expect, shar, language compilers,
382 gettext macros. Anything you don't install won't be tested. The test
383 suite will report on tests skipped due to software not available.
385 * Run the test suite in parallel (e.g., "make -j12 check"), both so it
386 doesn't take forever and because that is what most users will do. You
387 can also parallelize the makes that run inside each test with, e.g.:
388 make check AM_TESTSUITE_MAKE="make -j$(( 1*$(nproc) + 1 ))"
389 If you like, try different levels of parallelization to see what
390 runs the fastest on your machine. We'll use -j12 in our examples;
393 * To summarize, here is a typical make check invocation:
394 make -j12 VERBOSE=1 check keep_testdirs=yes
396 * Then check t/test-suite.log for the overall results. The directory
397 t/TESTNAME.dir is where the work will be left, if the test fails.
399 * You can run a single test, with, e.g.,
400 make check TESTS='t/aclocal-acdir.sh'
401 where t/aclocal-acdir.sh can be any t/*.sh test, including a new one
402 you are writing. You may want to add --no-print-dir to silence GNU
403 make about the many cd commands, and/or env VERBOSE=1 to get more
404 information about what make is running.
406 * Sometimes you may want to see when each test starts running, not only
407 when they complete. This can be done by setting TESTS_ENVIRONMENT:
408 make -j12 VERBOSE=1 TESTS_ENVIRONMENT='echo RUNNING: "$$f";' check
410 * Run "make maintainer-check" before commit. Watch out for trailing spaces.
411 Probably useful to run it more verbosely:
412 make AM_V_GEN= AM_V_at= VERBOSE=1 maintainer-check
414 * After "make -j12 check" succeeds. Run "make -j12 distcheck" before
415 pushing a commit, since that exercises yet more of the code.
417 * To unsilence Automake's "pretty" output for debugging, see the
418 "Unsilencing Automake" node in the manual. In short: run make --debug=p.
419 For the Automake test suite in particular, add VERBOSE=1.
421 * To set up a new test, first write the test file in t/good-name.sh.
422 Choose a name that fits with existing ones, as best you can devise.
424 - You'll likely want to copy material from an existing test, which is
425 fine and good; depending on how much is copied, it may be useful to
426 mention the other test(s) you used.
428 - Nevertheless, start the copyright year list in the new file fresh,
429 with the current year.
431 - You can run the new test on its own with
432 make check TESTS='t/good-name.sh'
434 - During development of a new test, it can be useful to end it with
435 "exit 33" (or any random value) to force it to fail even when it would
436 otherwise succeed, so you can inspect the test.dir/test.log and other
437 test.dir/* files to be sure things worked as expected.
439 - At some point before releasing, add the test to the appropriate
440 variable in t/list-of-tests.mk, most likely the (alphabetical)
443 * Some hints for debugging test failures or trying to understand the
444 (complex) test infrastructure.
446 - The t/ax/ dir contains most of the test infrastructure files.
448 - You may want to try a simple test just to exercise the setup;
449 t/amassign.sh is such a test. For a simple test that runs automake
450 twice (sometimes useful in finding concurrency failures), try
453 - To trace the (complex) test initialization code, change the set -e
454 to set -ex (or whatever you wish) in t/ax/test-init.sh.
455 Automake itself enables -x for the *.log and test-suite.log files,
456 in am_test_setup in t/ax/test-lib.sh. You may want to change to -vx.
458 - If you want to run the individual commands of a test one by one in a
459 shell, you have to reproduce the test environment. Start a subshell and:
460 PATH=$am/bin:$am/t/ax:$PATH # where $am is your automake source checkout
461 set +u # if needed; automake cannot handle this "nounset" option
462 . test-init.sh # beginning of test
463 Then each command you type will be executed in the test environment,
464 including -x being enabled. Each test prints the PATH value at the beginning.
466 - If you need to debug a test which fails under installcheck, you need
467 to invoke make with am_running_installcheck=yes, as is done by the
468 installcheck-testsuite target in t/local.mk.
470 - If you want to see the (complex shell) commands that make is
471 running, despite all of Automake's attempt at silence, run (GNU)
472 make --debug=p ... other make args ...
474 ============================================================================
477 * Automake uses the debbugs instance at https://bugs.gnu.org. Email
478 from the tracker is sent to bug-automake@gnu.org, and vice versa.
479 Ditto automake-patches@gnu.org. (See
480 https://gnu.org/s/automake for all the mailing lists; if you're
481 working on Automake, please subscribe.)
483 * To see all open bugs resp. patches (and recently closed ones):
484 https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=automake
485 https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=automake-patches
487 * For a full search form, initialized to show only bugs tagged confirmed:
488 https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake;include=tags%3Aconfirmed
490 * We use the "confirmed" tag to mean bugs that have been reviewed, are
491 evidently valid, but no one is currently working or plans to work on
492 them. Thus they are good candidates for new volunteers to get involved.
494 * To download the so-called maintainer mbox for a bug, say 12345:
495 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12345;mbox=yes;mboxmaint=yes
496 Only the maintainer mbox consistently has the bug# prefix on Subject:
497 lines, so it is the most usable, as far as we know.
499 * To close a bug, you can mail (or bcc) to 12345-done@debbugs.gnu.org.
500 It's best to do this with a note saying that the bug is being closed
501 because the fix was pushed, or whatever the reason.
503 * To add tags "help" and "confirmed" to bug 12345, mail to
504 control@debbugs.gnu.org with a one-line body:
505 tags 12345 + help confirmed
507 * To merge bugs 12345 and 56789, mail to
508 control@debbugs.gnu.org with a one-line body:
511 * In general, all bug operations are done by mail. Reference information:
512 https://debbugs.gnu.org/server-control.html # dev info
514 ============================================================================
517 * The steps outlined here are meant to be followed for all releases,
518 whether stable, beta, alpha, or other. Where differences are
519 expected, they will be explicitly mentioned.
521 * Fetch new versions of the files that are maintained elsewhere by
522 running "make fetch". help2man has to be updated separately. If
523 any files in the automake repository get updated, commit them and
526 * Ensure that the copyright notices of the distributed files are up to
527 date. The maintainer-only target "update-copyright" can help with this.
529 * Check NEWS; in particular, ensure that all the relevant differences
530 with the last release are included.
532 * Update the AC_INIT version number in configure.ac. Leading up to a
533 minor release (x.y), say 1.17, pretests should be numbered from
534 1.16.90. Even numbers (1.16.90, 1.16.92, ...) should be pretest
535 releases; odd numbers (1.16.91, 1.16.93, ...) should be only
536 development versions. Leading up to a micro release (x.y.z), say
537 1.17.1, we would have 1.17.0.91 for the initial post-release
538 development version, 1.17.0.92 for the first pretest, etc.
540 Before 1.17 (July 2024), we used suffixed letters for pretests, as is
541 traditional, but deficient sorting algorithms did not like that. The
542 code in lib/Automake/Version.pm, along with the regexp in
543 lib/Automake/Options.pm, has to be updated to understand any change in
544 version number schemes. The test t/pm/Version[.pl] comprehensively
545 checks valid and invalid version strings.
547 * If making a minor or major release (1.x), also update APIVERSION
548 in configure.ac. But not micro.
550 * Create an announcement message with "make announcement". Edit the
551 generated 'announcement' file appropriately, in particularly filling
552 in by hand any "TODO" left in there. It's useful to do this early,
553 because carefully writing the announcement can easily bring to light
554 things that still need to be worked on.
556 * Run these commands, in this order (as mentioned, adjust -j as desired):
558 make -j12 check keep_testdirs=yes
559 make maintainer-check
560 make -j12 check-no-trailing-backslash-in-recipes
561 make -j12 check-cc-no-c-o
562 make -j12 distcheck # regular distcheck
563 make -j12 distcheck AM_TESTSUITE_MAKE="make -j12" # parallelize makes
565 You can run "git clean -fdx" before invoking the bootstrap, to ensure
566 a completely clean rebuild. However, it must be done carefully,
567 because that command will remove *all* the files that are not tracked
568 by git! Run git status first to ensure all removals are ok.
570 * Create additional info for the announcement with the announce-gen
571 script that is part of gnulib (it requires the release tarball):
575 reltype=alpha # or beta or stable
576 host=`if test $reltype = stable; then echo ftp; else echo alpha; fi`
577 gpgkey=0x... # gpg --fingerprint
578 $gnulib/build-aux/announce-gen --release-type=$reltype \
579 --package-name=$pkg --previous-version=$prever \
580 --current-version=$newver --gpg-key-id=$gpgkey \
581 --url-directory=https://$host.gnu.org/gnu/$pkg
582 and merge this with the just-written announcement file.
584 * Run "make git-tag-release".
585 This will run the maintainer checks, verify that the local git
586 repository and working tree are clean and up-to-date, and create
587 a proper signed git tag for the release (based on the contents
590 * Run "make git-upload-release".
591 For pretest releases: "DEVEL_SNAPSHOT=1 make git-upload-release".
593 This will first verify that you are releasing from a tagged version
594 and that the local git repository and working tree are clean and
595 up-to-date, and will then run "make dist" to create the tarballs,
596 and invoke the 'gnupload' script sign and upload them to the correct
597 locations. In case you need to sign with a non-default key, you can
598 use "make GNUPLOADFLAGS='--user KEY' git-upload-release".
600 * For stable releases you also need to update the manuals on www.gnu.org.
604 make checklinkx # various perl prerequisites, see contrib/checklinkx
606 <https://validator.w3.org/checklink>
608 - Generate manuals (with the help of the standard gendocs.sh script):
611 The ready-to-be-uploaded manuals (in several formats) will be left
612 in the 'doc/web-manual' directory.
614 - Commit the updated manuals to web CVS. This requires the "cvsu"
615 utility from the "cvsutils" package.
616 make web-manual-update
618 If your local username is different from your username at Savannah,
619 you'll have to override the 'CVS_USER' make variable accordingly;
621 make web-manual-update CVS_USER=slattarini
623 * Update version number in configure.ac to next alpha number.
624 Rerun ./bootstrap and commit.
626 * Don't forget to "git push" your changes so they appear in the public
629 * Send the announcement generated in the earlier steps at least to
630 <autotools-announce@gnu.org> and <automake@gnu.org>. If the release
631 is a stable one, the announcement also goes to <info-gnu@gnu.org>;
632 if it is an alpha or beta release, announcement should be sent also
633 to <platform-testers@gnu.org>, to maximize the possibility of early
634 testing on the widest variety of systems. Finally, copy an abridged
635 version of the announcement into the NEWS feed at:
636 <https://savannah.gnu.org/projects/automake>.
637 Be sure to link a version to the complete announcement (from
638 the version you sent to the automake list, as archived at
639 <https://lists.gnu.org/archive/html/automake/>).
642 Copyright (C) 2003-2024 Free Software Foundation, Inc.
644 This program is free software; you can redistribute it and/or modify
645 it under the terms of the GNU General Public License as published by
646 the Free Software Foundation; either version 2, or (at your option)
649 This program is distributed in the hope that it will be useful,
650 but WITHOUT ANY WARRANTY; without even the implied warranty of
651 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
652 GNU General Public License for more details.
654 You should have received a copy of the GNU General Public License
655 along with this program. If not, see <https://www.gnu.org/licenses/>.