SQL Version

[John Ralls]

On Jan 31, 2011, at 8:49 AM, Derek Atkins wrote:

> John Ralls <jralls at ceridwen.us> writes:
> 
>> On Jan 31, 2011, at 7:50 AM, Derek Atkins wrote:
>> 
>>> John Ralls <jralls at ceridwen.us> writes:
>>> 
>>>> The versions table is defined with an int in the second field, which is why the git hash isn't writing.  There's likely an error message about that in Geert's gnucash.trace.
>>>> 
>>>> So we can use a serial number in gnc-version.h or construct an int out of the release version in configure (perhaps with a "micro" component added in on trunk for when we need to change things between releases). I'm inclined towards the latter, because it's mostly automatic. Do you really feel strongly about having a serial number instead?
>>> 
>>> I think generating something from the version number would be fine, if
>>> we can figure out some way to handle it (sort of like a DNS SOA serial
>>> number).  Something like GnuCash version x.y.z -> XXYYZZVV
>>> 
>>> The hard question is:  how do we encode the 'VV' version such that it
>>> gets reset to 0 whenever we reset the gnucash version in configure.ac?
>>> 
>>> Any system we use has risks and problems.
>> 
>> Well, I implemented exactly that over the weekend. "VV" is
>> GNUCASH_NANO_VERSION, and it's in configure.ac right underneath the
>> AC_INIT that sets the rest of the versions so that it will be easy to
>> remember to zero out when the version number gets bumped.
> 
> Yeah, I saw that as I was going through the patches after I sent this.
> How is this any different than just setting a number in
> e.g. gnc-sql-schema-version.h?  A developer still needs to remember to
> update the nano-version any time they make a schema change..
> 
> But the current method also means that gnucash 2.4.2 and 2.4.3 would
> consider themselves different even if the schema does not change.

Yes, it does still depend on a developer remembering to increment the nano-version if he changes something (and as I keep pointing out, it can be a change in engine, business, or qof, not just the schema). But remember that there are two components: The actual version which last touched the database (Gnucash version) and the GNC_RESAVE_VERSION which marks the boundary for too-new and too-old. Too-old will force a resave, too-new will force read-only. That's currently declared in gnc-backend-sql.h; I should probably move it to configure as well so that it's more visible.

Regards,
John Ralls