Re: Patches to README-release

[Gary V. Vaughan]

Hi Jim,

On 28 Jan 2012, at 15:27, Jim Meyering wrote:
> Gary V. Vaughan wrote:
>> Hi Jim,
>> 
>> On 28 ม.ค. 2012, at 1:21, Jim Meyering <address@hidden> wrote:
>> 
>>    Reuben Thomas wrote:
>> 
>>        Ping? The patches still apply cleanly to HEAD.
>> 
>>        On 22 December 2011 19:54, Reuben Thomas <address@hidden> wrote:
>> 
>>            -* Ensure that the desired versions of autoconf, automake, etc.
>>            -  are in your PATH.  See the buildreq list in bootstrap.conf for
>>            -  the complete list.
>> 
>>    That paragraph is trying to say that one should be careful not to
>>    prepare a release using anything less than the latest stable releases.
>>    That is *not* checked by running bootstrap, and hence why I mentioned
>>    it here.  For example, if I have a working directory with lib/getdate.c
>>    generated from before the preceding bison release, I should be careful
>>    to remove it (make maintainer-clean) and regenerate it with the newer
>>    version of bison.  In this case, "make distclean" is insufficient.
>> 
>>    I.e., you're welcome to reword it, but not to remove it altogether.
>> 
>> How about:
>> 
>> If you have not yet upgraded to saner bootstrap, which check autotools
>> versions automatically for you, then you'll need to make a painstaking
>> manual check of the autotools versions in your PATH every time you
>> want to make a new distribution tarball.
> 
> You have missed the point.
> When I make a release, I want to use at least the latest stable
> build tools.  AC_PREREQ does not necessarily encode that requirement.

Well, that *was* my point.  I'm wondering what purpose AC_PREREQ (etc) really
serves if you're not using them to encode the versions of the autotools that are
required to bootstrap a package in the way expected by the maintainers.

In other words, does it really make sense to keep track of the minimum version
capable of bootstrapping one's project, when you really want people to bootstrap
with the latest stable version before crashing your project and sending you bug
reports?  Why keep track of two versions of each tool at all, when AC_PREREQ 
(etc)
can easily be used to (a) prevent people from re-bootstrapping with untested
autotools (b) automatically inform bootstrap of the versions of autotools that 
the
maintainers are using and testing during development, rather than remembering to
keep $buildreq and AC_PREREQ in sync by hand?

On the other hand, if there's a genuine use case for allowing rebootstrapping
with likely working, but equally likely untested, old autotools releases... then
I need to remove the automatic autotools version extraction code from saner
bootstrap and instead flag an error if $buildreq doesn't specify the maintainer-
tested autotool versions (irrespective of what AC_PREREQ et al. might say).

(The bison issue you raise is interesting too, although not so difficult since
$buildreq should already be listing the required bison version, so there's no
conflict with some older version that will probably work listed somewhere else.
IMHO rebootstrapping a project prior to rolling a release should diagnose any
deficiencies in installed build tools to prevent propagating known bugs from
old build tool releases.)

WDYT?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)