Peter Simons wrote:
> Karl Berry writes:
> > However, I also see no harm in looking at the first 20 lines instead
> > of the first 10 lines to match the version.
>
> yes, I agree with Karl here. The current implementation enforces a
> policy that feels rather odd. A NEWS file that features the release
> heading in line 10 is considered valid, but one that features the
> heading in line 11 is not. This is really quite arbitrary and not
> particularly intuitive.
The penalty for an inadequate test would be to release without updating NEWS.
That particular file is so visible that I think it's worth making the default
test
very strict.
As with nearly all gnulib-imported files, if you don't like
the way it's done by default, you have options:
- disable this particular test
- patch the file (via gnulib-tool) to test the way you'd prefer
FYI, other tools (build-aux/do-release-commit-and-tag) require
that line 3 of NEWS contain the magic line, so relaxing this test to
look at 10 lines was already throwing a bone to those who do things differently.
$ build-aux/do-release-commit-and-tag --help
Usage: do-release-commit-and-tag VERSION RELEASE_TYPE
Run this script to perform the final pre-release NEWS update
in which the date, release-type and version string are recorded.
Commit that result with a log entry marking the release, and apply
a signed tag. Run it from your project's top-level directory.
Requirements:
- you use git for version-control
- a NEWS file, with line 3 identical to this:
* Noteworthy changes in release ?.? (????-??-??) [?]
- a version-controlled .prev-version file
Options:
--help print this help, then exit
--version print version number, then exit
EXAMPLE:
To update NEWS and tag the beta 8.1 release of coreutils, I would run this:
do-release-commit-and-tag 8.1 beta
Report bugs and patches to <bug-gnulib@gnu.org>.
