Re: GNU Automake 1.14 released

[Stefano Lattarini]

[Re-adding the list, sorry for the confusion]

On 08/12/2013 06:16 AM, Eric Dorland wrote:
> * Stefano Lattarini (address@hidden) wrote:
>> Hi everybody.
> 
> (You didn't reply to the list, did you mean that?)
>
No, thanks for noticing.  I'm re-adding the list.

>> Sorry for the delay,
>
Ditto.

>> but real life is being quite intrusive these
>> days (so expect similar delays in the near future as well; sorry!)
>>

>> On 09/08/13 07:55, Eric Dorland wrote:
>>> * Dan Kegel (address@hidden) wrote:
>>>> On Thu, Aug 8, 2013 at 4:43 PM, Eric Dorland <address@hidden> wrote:
>>>>>> That sounds kind of risky, promises of compatibility notwithstanding.
>>>>>
>>>>> Can you elaborate why?
>>>>
>>>> No.  I'm just being paranoid.  But there is good precedent for
>>>> paranoia being the right setting in matters of backwards compatibility.
>>>>
>>>>> If the promise of compatibility is real, what's the downside?
>>>>
>>>> I can think of two:
>>>> 1) users wanting to check to see if their code is compatible with
>>>> automake-1.13
>>>> 2) users wanting to regenerate the same data file as automake-1.13
>>>> did, to avoid unneeded diffs
>>>
>>> While I can sympathize with these use cases, Debian isn't there to
>>> provide every version of automake. The vast majority of packages do
>>> not get multiple versioned in Debian and when we do it's almost always
>>> the minimum number of versions necessary.
>>>
>>> If these are the only use cases I don't think that justifies carrying
>>> the extra version.
>>>
>> Well, we now promise to be *mostly* compatible between minor releases,
>> but also explicitly state that we might break such compatibility in
>> corner case if that is done to fix bugs or broken behaviours (while
>> between micro releases, not even that form of compatibility breakage
>> is acceptable).  This is not merely theoretical -- here is an
>> example of such a bugfix:
>>
>>   <http://comments.gmane.org/gmane.comp.sysutils.automake.bugs/6367>
>>
>> Or, for a more recent example, take a look at the "C compilation,
>> and the AC_PROG_CC and AM_PROG_CC_C_O macros" section of the
>> Automake 1.14
>> announcement:
>>
>>   <http://lists.gnu.org/archive/html/automake/2013-06/msg00040.html>
> 
> As long as the number of users affected as small, ie it affects a very
> small percentage of Makefile.am's then I don't really see this as a
> problem.
>
The author of those Makefiles might disagree.

> For example I hope you would be unwilling to break 25% of
> Makefile.am's even if they're relying on some undocumented behavior in
> a minor release.
>
Yes, I would be unwilling.  But I've also learned that it's often
difficult to estimate which percentage of Makefiles can be broken
by an apparently minor incompatibility...

>> Another point is that we feel free to introduce new non-fatal
>> deprecation warnings in new minor release, so a Makefile.am that
>> was perfectly valid with Automake 1.13 could cause Automake 1.14
>> to spew tons of warnings (albeit the generated makefile should
>> keep working as expected).
> 
> I don't really see that as a problem or a good reason to keep lots of
> versions of automake in Debian.
>
Well, you being the maintainer for the Automake Debian package,
that decision is up to you.  I'm just offering my opinion; then
we can agree to disagree, without problem.

>> In the end, I'd like for APIVERSION to remain based on the minor
>> version number.  It seems less risky that way.
> 
> It's safer I suppose but it doesn't really seem correct.
>
Sometimes safer is better IMHO.

>>>>>> If I were sticking my neck out, I'd keep on with the old scheme,
>>>>>> where automake-1.13 means automake 1.13.  It would surprise people less.
>>>>>
>> This is what I'd prefer as well.
> 
> I'm still not convinced it's necessary. There's a lot of cost and
> confusion to keeping so many versions.
>
There is a trade-off, sure.  Deciding whether or not this cost is worth
paying in Debian is up to you (my opinion is that it is worth, as you
might have surmised).

>>>>> Well I think if it doesn't work it shouldn't be difficult to down the
>>>>> road provide an automake1.13 package. So the risk doesn't seem that
>>>>> high.
>>>>
>>>> But you will still surprise users in the two categories I mentioned.
>>>> - Dan
>>>>

Regards,
  Stefano