* Dan Kegel (d...@kegel.com) wrote: > On Thu, Aug 8, 2013 at 2:39 PM, Eric Dorland <e...@debian.org> 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 <e...@kuroneko.ca> ICQ: #61138586, Jabber: ho...@jabber.com
signature.asc
Description: Digital signature
