Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

[Daniel Herring]

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