Re: GNU Automake 1.14 released

[Eric Dorland]

* Stefano Lattarini (address@hidden) wrote:
> [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.

I'm sure they would, but as long as they're a small enough minority I
think this is still justifiable.
 
> > 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...

I'm sure it is. But as long as you're willing to roll back that sort
of breakage once you learn about it I'm not *too* concerned.

> >> 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.

Indeed, that's why we're having this conversation :)

I just want to make sure I understand what you're promising with the
new version scheme so that expectations can be met.

> >> 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).

So I've upgraded the automake pacakage in unstable to 1.14. In a
future upload I'm planning to make that package "provide" automake1.13
so that if anyone wants automake1.13 they'll get automake 1.14. If
there's any complaining this is easy enough to undo, where we provide
a dedicated automake1.13 package and drop the provides from the 1.14
version.

Sounds acceptable?

> >>>>> 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
> 

-- 
Eric Dorland <address@hidden>
ICQ: #61138586, Jabber: address@hidden

signature.asc
Description: Digital signature