[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 17:39:41 -0400 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
* Eric Dorland (address@hidden) wrote:
> Hi Stefano,
>
> I was just getting around to packaging this for Debian and I have a
> question. Given the new versioning scheme shouldn't the APIVERSION (as
> defined in configure.ac) be 1.13 and not 1.14? Or more precisely, does
> it make sense for the binary to be renamed given that this release
> should have no backwards incompatibility with 1.13?
OK given the lack of response I'll just describe my plan for Debian
for 1.14 and people can yell if they think I'm doing it wrong.
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.
Makes sense? Any questions, comments or concerns?
--
Eric Dorland <address@hidden>
ICQ: #61138586, Jabber: address@hidden
signature.asc
Description: Digital signature
- Re: GNU Automake 1.14 released,
Eric Dorland <=