On Jan 31, 2011, at 8:49 AM, Derek Atkins wrote: > John Ralls <jra...@ceridwen.us> writes: > >> On Jan 31, 2011, at 7:50 AM, Derek Atkins wrote: >> >>> John Ralls <jra...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
