Re: please bring back program suffix for autoconf bin files

[Charles Wilson]

Russ Allbery wrote:
> The problem you're encountering is that the Autoconf maintainers,
> even more than not being interested in supporting use of 2.13,
> actively dislike it and actively want it to disappear.  So making it
> easier for people to locate and run Autoconf 2.13, or any other
> version than the current one, is contrary to the current development
> goals.

But that is incorrect (in that it won't achieve the goal of flushing the 
old version out of the pipe, as it were).  By forcing flag days onto all 
developers AND all projects, that attitude actually *retards* acceptance 
of the new version.  Nobody wants to risk switching until they KNOW that 
everything will work properly "on the other side" -- and that goes for 
developers as well as projects.  The result: nobody switches (or 
switchovers happen slowly)  As I said earlier:

----
> Making it easy for people to have BOTH the old autoconf (e.g. 2.5x)
> and the new autoconf (e.g. 3.x) installed on *the same system* will
> actually *speed* adoption of the new tool; the current irretrievable
> situation w.r.t. 2.13 and 2.5x has, IMO, slowed migration because of
> (reverse) network effects: Joe developer can't switch his system over
> to 2.5x until most of the projects he hacks have already made the
> switch; but project X can't "flag day" over to 2.5x until most of its
> developers have updated their systems.  Result: 18 months since 2.50
> was released, and gcc -- GCC!!! -- is just now beginning to switch
> over...
----

My point: if you want to get rid of "the old version" faster, design the 
new version to co-exist. It's couterintuitive, but true.  Unfortunately, 
it's probably too late to clean up the mess that was/is the 2.13->2.5x 
switch, but it's something to think about for the future...

--Chuck