Re: branch rewind

Eric Blake <ebb9 <at> byu.net> writes:

> 
> Heads up to anyone tracking branch-1_4 on git.  I have just created branch-
1.6 
> which will continue to be the development track towards the next stable 
release 
> of M4 containing the argv_ref speedups, and will soon be rewinding the branch-
> 1_4 branch back to v1.4.10 to apply minimal changes and do a release of 
1.4.11 
> that works out of the box on BSD-based systems.  My intention is for 1.4.11 
to 
> be the end of the 1.4.x branch, and convert all 'stable' development to 
1.6.x, 
> leaving all development regarding modules as 2.0 on the master branch.

Done.  To make it clearer, I renamed the 1.4.x branch to branch-1.4, to match 
the spelling of branch-1.6 (I'm not a fan of needless use of the shift key; the 
only reason the old name was branch-1_4 was that it matched the CVS branch 
name, and CVS doesn't allow . in branches :)

I'm still waiting on a couple of gnulib fixes before I can release M4 1.4.11 - 
strtod needs help to be C99 compliant (I have a partial patch sitting in my 
sandbox; it supports parsing 'inf' and 'nan' and works around bugs when 
parsing '0x', but doesn't yet parse hex floats).  Also, on cygwin, test-fflush2 
needlessly fails, since it assumes semantics of ungetc which are contrary to 
what the austin group just recommended; Bruno promised to fix the ungetc-
related tests to match the austin group recommendations.

Anything else that needs to go into the release?  I'm hoping to get it done 
within the week; right now, I'm aiming to do m4 1.4.11 first, and autoconf 2.62 
second, so that autoconf can be patched to recommend m4 1.4.11.

-- 
Eric Blake