GNU bug report logs - #13578
A new versioning scheme for automake releases, and a new branching scheme for the Git repository

Previous Next

Full log

View this message in rfc822 format

From: Daniel Herring <dherring <at> tentpost.com>
To: automake <at> gnu.org, 13578 <at> debbugs.gnu.org
Subject: bug#13578: [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)

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.

http://www.gnu.org/software/automake/manual/html_node/API-Versioning.html


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.

http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html
http://semver.org/

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,
Daniel

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.