Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

From: Dave Goodell <[email-masked]>
Date: Tue, 29 Jan 2013 08:22:42 -0600

On Jan 29, 2013, at 6:18 AM CST, Peter Johansson wrote:

> On 1/29/13 5:48 AM, Stefano Lattarini wrote:
> 
>> Another plus of this new versioning scheme is that it will allow
>> different minor releases, even with the same major version, to
>> co-exist on the same system (that's because the $(APIVERSION)
>> variable will get bumped with each minor version now).
> 
> Why is that a plus? What is the use case when I want to keep on using Automake 2.1 after I have installed Automake 2.2? Assuming 2.2 is 100% backward compatible I cannot see the use case. What am I missing?

As a developer, it can be surprisingly difficult to write autotools code that is portable to several different versions of the autotools.  Sometimes it's convenient to only choose to support some subset of the autotools version space.  Development bandwidth, lack of autotools expertise, and limited access to testing platforms are all reasonable reasons that lead to this sort of decision.

This in turn causes problems for packagers, since different packages choose different subsets of the versions space.  So as a packager, you end up either:

1) attempting to patch all of the packages which are incompatible with your versions of the autotools, which is risky and time-consuming; or

2) juggling several different autotools version tuples.  Anything that makes this difficult quickly can turn into a real PITA.  Anything that makes it easier is always welcome.

Putting the developer hat back on, facilitating multiple versions also makes it easier to test with each of those versions.

-Dave