[Re-adding the list, sorry for the confusion] On 08/12/2013 06:16 AM, Eric Dorland wrote: > * Stefano Lattarini (stefano.lattar...@gmail.com) 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 (d...@kegel.com) wrote: >>>> On Thu, Aug 8, 2013 at 4:43 PM, Eric Dorland <e...@debian.org> 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
