* Eric Dorland (e...@debian.org) 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 <e...@kuroneko.ca> ICQ: #61138586, Jabber: ho...@jabber.com
signature.asc
Description: Digital signature
