Bruno Haible <br...@clisp.org> writes: > Jim Meyering wrote: >> Here's a proposed (I confess, untested) patch for that: > > This patch makes things even more complicated. > > How about making is simpler, by changing the maintainer's use from > > make release RELEASE='1.2 stable' > > to > > make release VERSION=1.2 RELEASE_TYPE=stable > > ? > > Additionally, I don't understand why, after the complicated > business with .tarball-version that the GNUmakefile forces upon > the maintainer, here is *another* way to specify the version? > Why two different mechanisms to do the same thing? Is the > .tarball-version thing not working for you?
I think we need one manually invoked rule like 'release-commit' to
create a version tag and set the release type, since this information
cannot come from any other place but the maintainer. The file
.tarball-version is generated, isn't it? So I think this is okay:
make release-commit RELEASE='1.2 stable'
We could improve the user interface like with some better naming:
make release-commit VERSION=1.2 TYPE=stable
However I agree with you that it is strange to have to provide the same
information AGAIN when using 'make release'. I don't like to think
about what happens if the information differ? I think the command
should simply be:
make release
The version and type should be then be read from the NEWS file, in the
format that 'release-commit' wrote it. If NEWS isn't updated properly,
fail.
Same for uploading, currently we have to write
make upload RELEASE='1.2 stable'
and this information could have come from NEWS too.
While we are on the README-release subject, this line garbage always
bothered me:
c=check ve=check-very-expensive; git grep -q "^$ve:\$" && c=$ve
make $c syntax-check distcheck
For easier reading, I think it should be:
make check syntax-check distcheck
and the few packages that have a check-very-expensive rule could patch
the file.
But these are just some opinions, no patches provided :-)
/Simon
signature.asc
Description: PGP signature
