Version Numbering

[Christian Stimming]

Am Montag, 23. März 2015, 09:20:56 schrieb John Ralls:
> > Instead,
> > from my point of view we should consider incrementing our first version
> > number from 2 to 3 at some not-too-distant point in the future, as soon
> > as this number change would represent something useful for the user. For
> > example, a gnucash version that is multi-user-enabled would be enough of
> > a reason to call that "version 3.something". Note that I don't care at
> > all which technology was used to achieve this feature.
> 
> Good point, but where do we draw the line? Do we follow Firefox and use only
> two numbers, so we have a new first-digit release every 3 years?

John,

I also don't have a final answer to this question. The important point from me 
is that we shouldn't be more shy than necessary w.r.t. increasing the first-
digit number. My criterion would be the vague "If something important changes 
that is important to many users", and indeed that's rather vague and needs to 
be revisited each time we start the next stable series.

In case of 2.4 -> 2.6: From what I recall there were no real "important change 
for many users", so in that case increasing only the second digit was just 
fine. 

If next time we have the same situation - fine, let's go to 2.8. 

But after that, I would suggest to be somewhat more reluctant to go to a two-
digit minor number, i.e. before switching to 2.10 we should rather switch to 
3.0 even if the set of new feature is again in a similar range as it was in 
the 2.4->2.6 switch. A two-digit minor number makes things more confusing than 
necessary and I would rather like to avoid that. But that's a future 
discussion and not today's topic.

Maybe the 2.2->2.4 switch had enough changes so that we could have gone to 3.0 
instead. But that's long ago and just hypothetical.

Yes, the points you raise can give valid arguments: multi-user; file 
compatibility; script API. To summarize, I think we do not have to draw clear 
lines right now, but can live with a rather vague description of our policy, 
and make the actual decisions about the numbering of the next stable series 
right at the point when we know what will be in there.

Regards,

Christian

> 
> I don't think that there's any argument that multi-user justifies a new
> first-digit number, but I also think it's pretty optimistic to plan for it
> in the next major release. Unless you're advocating for the Firefox model
> (minus the every-few-months bit, we don't have the resources for that),
> what else do you think might justify a first-number change? Do you think
> that 2.6 should have been 3.0?
> 
> What about API breaks in the Scheme and Python bindings? Not something most
> users care about, but folks with custom scripts sure do. We've always said
> that we don't guarantee API stability between major versions, but we also
> promote the bindings pretty heavily.
> 
> I suspect that users care most about file compatibility. We've done pretty
> well on that through the 2.x series, but along with multi-user will come a
> shift from default XML to default SQL, and going forward from that we'll
> want to normalize the schema, especially to move stuff out of slots.
> 
> The two combined would be a useful guideline: first-number changes mean that
> you'll have to revisit your scripts or your database will be upgraded so
> that it's not readable by the previous version except the closeout release.
> 
> Regards,
> John Ralls