Build Master: Scheduling

[luka8088]

On 15.11.2013. 11:01, Jacob Carlborg wrote:
> On 2013-11-15 10:16, luka8088 wrote:
> 
>> Yes. For example, if you have version 0.1, 0.2 and 0.3. And you find and
>> fix a bug in 0.3 but you still wish to support backport for 0.2 and 0.1
>> that you indeed need to make 3 releases. 0.1.1, 0.2.1 and 0.3.1.
> 
> There's a difference in still supporting old releases and working on
> five different releases at the same time that hasn't been released at all.

Yeah. I agree. Bad idea.

> 
>> But then again having LTS that others have mentioned seems better. So
>> that only each nth release has 2.x.1, 2.x.2, 2.x.3.
>>
>>  From my perspective, not separating releases with improvements + bug
>> fixes from releases with only bug fixes is an issue. Because every new
>> improvement implies risk of new bugs and some users just want to have
>> one version that is as stable as possible.
>>
>> What do you all think about http://semver.org/ ?
>> We use this king of versioning notation at work and it turns out to be
>> very good.
> 
> I like it but I'm not sure who it's applied to applications. It's clear
> to see how it works for libraries but not for applications. I mean, what
> is considered an API change for an application? Changing the command
> line flags?
> 

I think API change could be analog to features change (and the way they
are interfaced).

So the version consists of x.y.z

z increments only on bug fixes.
y increments when new features are added, but they are backwards
compatable. Incrementing y resets z to 0.
x increments when backwards incompatible change are made. Incrementing x
resets y and z to 0.