SQL Version

[John Ralls]

On Jan 28, 2011, at 9:16 AM, Derek Atkins wrote:

> Geert Janssens <janssens-geert at telenet.be> writes:
> 
>> On Friday 28 January 2011, John Ralls wrote:
>>>> I just remembered the discussion some time ago about the choice of the
>>>> revision number as table version number. I am building GnuCash from a
>>>> local git repo, which I keep synchronized with svn. Perhaps that's the
>>>> cause ?
>>> 
>>> Possible, I suppose. What's in src/core-utils/gnc-svninfo.h?
>>> 
>> $ cat BuildWebkitDbg/src/core-utils/gnc-svninfo.h 
>> /* Autogenerated. Do not change. */
>> #define GNUCASH_SVN_REV "f9cd753+"
>> 
>> That matches the git hash for the commit used build GnuCash.
>> 
>>> Seems just as likely that safe_sync doesn't write the current version
>>> number. If you add a transaction after opening does the line Gnucash |
>>> 20181 (or whatever version is showing up in gnc-svninfo.h) get added?
>>> 
>> No, it's still 
>> Gnucash-Resave|19920
> 
> And already we hit the "version is not a monitonically increasing
> number" issue.   :-D
> 
> Seriously, we should just have a "schema version" defined in a header
> file somewhere and just "remember" to change it whenever we make schema
> changes.  The 'gnucash version' (and revision string) should only be
> there for informational purposes.

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?

Regards,
John Ralls