[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IMPORTANT] A new versioning scheme for automake releases, and a new

From: Daniel Herring
Subject: Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Date: Tue, 29 Jan 2013 22:30:47 -0500 (EST)
User-agent: Alpine 2.02 (LNX 1266 2009-07-14)

On Mon, 28 Jan 2013, Stefano Lattarini wrote:

Feedback, opinions, objections?

There was a lot to read, and I confess to not giving it full justice.

Others have already extolled the virtues of backwards compatibility.

Regarding some "why" questions, here's the manual entry on how versioning is used today.

As far as I can tell, the current proposal boils down to "bump the major version more often". That can work, but I'm not quite sold on it. I like when a major bump means "wake up and reread the docs before upgrading" and minor bumps mean "upgrade casually". (and aggregate changes to minimize major bumps and make them more worthwhile)

Here are a couple "standards" for versioning.

The general principle being A.B.C decodes to something easy like
A = new API, breaking changes requiring human intervention
B = same API, maybe with added options, mostly just recompile
C = just bugfixes, documentation tweaks, packaging, etc.

For example, a deprecation warning bumps B, but actually removing the deprecated functionality bumps A.

As for branching, if every release is tagged, and you want to apply a bugfix to release A.B.C, why not just create a maint-A.B branch or the like? Delay creating branches until they are needed. I wasn't seeing the need for the complex branching details.

I agree its nearing time for a "2.0" release; there has been talk of removing several now-deprecated functions and making other major changes (e.g. parallel testing). Would it be possible to start collecting these into a preview/beta release and leave the "1.0" series with its current API and behaviors? Just a thought.

I've done the build system for several projects I'm no longer associated with. It would be nice if the people who inherited them don't have to rework them for a few more years. A major version change (again, small numbers) might motivate distributions to keep both around for a while.

Hope that helps,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]