[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU Automake 1.14 released
From: |
Eric Dorland |
Subject: |
Re: GNU Automake 1.14 released |
Date: |
Thu, 8 Aug 2013 19:43:26 -0400 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
* Dan Kegel (address@hidden) wrote:
> On Thu, Aug 8, 2013 at 2:39 PM, Eric Dorland <address@hidden> wrote:
> > Previously I would upgrade the automake package to the latest version
> > and add a new binary package for the previous version. So, for
> > example, if automake was at version 1.10 and 1.11 was released
> > upstream I would update the automake package to 1.11 and create a new
> > automake1.10 package for people who couldn't deal with the backwards
> > incompatibility.
> >
> > Given the new version scheme, 1.14 should be backwards compatible with
> > 1.13. So my plan is to upgrade the automake package to 1.14, have it
> > "Provides: automake1.13" and add symlinks from /usr/bin/automake-1.13
> > to /usr/bin/automake-1.14 (since 1.14 creates only the automake-1.14
> > binary). I will not provide an automake1.13 package with the older
> > version since that doesn't make sense if 1.14 is properly backwards
> > compatible.
>
> That sounds kind of risky, promises of compatibility notwithstanding.
Can you elaborate why? If the promise of compatibility is real, what's
the downside?
> 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.
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.
--
Eric Dorland <address@hidden>
ICQ: #61138586, Jabber: address@hidden
signature.asc
Description: Digital signature