Re: [Automake-ng] [FYI] [ng] maint: use name "Automake-NG" in more places, bump version

[Stefano Lattarini]

On 02/17/2012 06:16 PM, Dave Hart wrote:
> On Thu, Feb 16, 2012 at 22:27, Stefano Lattarini
> <address@hidden> wrote:
>> It's time to start renaming this project for good, if we want to
>> avoid nasty confusions with mainstream Automake.  But renaming also
>> the 'automake' script to 'automake-ng' could cause gratuitous
>> incompatibilities and unexpected errors, so we prefer to instead
>> bump the version from '1.11a' to '2.0a'.
>>
>> The renaming "Automake" -> "Automake-NG" is mostly for README files
>> and some comments.  Doing that for the documentation would be
>> trickier, and might cause extra spurious conflicts when we merge
>> 'master' into 'ng/master', so we leave that move for a later time.
> 
> When you first proposed dropping make portability from an Automake
> fork, you proposed calling it Automake 2.0.  After some expressed
> their desire to see make portability continue in Automake, which such
> naming suggested was coming to an end, you settled on Automake-NG.  At
> least I think I wasn't alone in valuing distributing tarballs that
> don't have recent GNU make as a build prerequisite.
> 
> Now you say you're "renaming this project for good" but what I see is
> cursory renaming and co-opting of the 2.0 version number from
> traditional Automake.
>
Well, at first I had thought about using the version number 0.5a, but
then I realized that doing so would have possibly caused missing
warnings for projects requiring a minimal Automake API version in
'AM_INIT_AUTOMAKE'; for example, a project whose configure.ac contains:

  AM_INIT_AUTOMAKE([1.10])

would (rightfully) trigger a complaint from Automake 1.11.1, but none
from Automake-NG.  Highly unexpected IMO.  So I took the "short-cut" [1]
of bumping the Automake-NG version number to avoid this situation.

But then, as you've pointed out, labelling Automake-NG as "2.0" will only
mud the waters about what the "real" / "more recent" Automake is, and
cause even more confusion about the Automake vs. Automake-NG distinction.
Which is precisely what we don't want.

So I now believe that the best way to proceed to avoid the pitfall
described above is to add a new special "ng" option, that Automake-NG
will *require* to see in order to proceed; this way:

  - if a user tries to run mainstream Automake on a project requiring
    Automake-NG, he will see an error from automake about "unknonwn
    'ng' option";

  - if a user tries to run Automake-NG on a project expecting to be
    bootstrapped with Automake, he will see a proper complaint from
    Automake-NG ("this project does not provide an 'ng' option to
    Automake -- it might not work with Automake-NG, you should use
    mainstream Automake instead).

I will follow in the next days with a patch providing the version "downgrade"
(2.0a -> 0.5a) and with another one providing this new 'ng' option.  Of
course, if someone wants to speed out this steps, patches are welcome.

> Congratulations on achieving your original goal.
> 
> Disgusted,
> Dave Hart
>
Wow, I would have never thought that an apparently innocuous (albeit
misguided) version bump could cause someone of accusing me of trying to
purposely derail the Automake project itself :-(

Maybe, next time, try to be more propositive and less accusatory (not to
say disrespectful); your aggressive tone has almost caused me to answer
your badly-expressed but otherwise very sensible objection with a couple
of snide remarks (which in the end would have hurt you, me, Automake and
Autoake-NG at the same time).

Stefano

[1] If anything, this thread give another proof of the fact that a short-cut
is often the longest path between two points.