Version Numbering

John Ralls jralls at ceridwen.us
Sun Mar 22 20:20:56 EDT 2015


> On Mar 23, 2015, at 6:41 AM, Christian Stimming <christian at cstimming.de> wrote:
> 
> Dear Chris,
> 
> thanks for bringing up this question. In fact there are different views on 
> this topic around. I consider the version number as part of our marketing 
> communication to potential users. As such, the first-most number of our 
> software should represent something that is meaningful to the users. And it 
> should change as soon as something major that is meaningful to the users is 
> changed.
> 
> I've simply seen enough users who can't tell whether there is a version 2.2 or 
> 2.4 or 22 or 24 or whatever of gnucash on their computer. They could for sure 
> tell whether they have version 2-something or 3-something. But the next number 
> is just magnitudes less important. Hence, we should use the important part of 
> the version number as our product marketing in a useful way.
> 
> Because of this, I am against the idea that we have to stick to the first 
> number "2" unless we have a major architectural change or some other whatever 
> major technological yadda yadda change inside gnucash. 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.
> 
> Thing is, we can expect all users to tell whether their gnucash version number 
> starts with 2 or 3. But the number after that is already something that can be 
> remembered by only a minority of the users. Why should we easily let go of the 
> powerful communication tool to tell whether someone has a newer or older 
> version of the software? Instead, IMHO we should keep in mind to switch to 
> version 3.x within the next 1-3 years, as soon as we have enough user-visible 
> to justify this change.

Christian,

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?

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




More information about the gnucash-devel mailing list