On Dec 7, 2011, at 6:43 AM, Derek Atkins wrote: > Mike Alexander <m...@umich.edu> writes: > >> --On December 6, 2011 3:01:54 PM -0800 John Ralls <jra...@ceridwen.us> >> wrote: >> >>>> This is not the optimal solution, but the best I can come up with in >>>> my available time and with the state of the backends as they are >>>> now. >>> >>> No, I think that's got it. >>> >>> If you can't handle credit notes in 2.4 without too much of a change, >>> you could detect them at load and raise ERR_BACKEND_TOO_NEW, though I >>> admit that's not much of an improvement over failing to load because >>> of an unrecognized element. >> >> Could you bump the file version number only if credit notes exist in >> the file? Or bump it the first time a credit note is used (leaving it >> bumped if all of them later get deleted)? That might give you the >> best of both worlds: strict versioning, but old versions of Gnucash >> could open data files that don't use credit notes. >> >> Actually you wouldn't literally bump it, but rather set it to n if it >> is less than n (where n is the first version that supports credit >> notes). Would this work? > > This is effectively my "feature" flags suggestion from before. You flag > (new) features as they are used, and refuse to load the database if > there are used features that you don't understand.
Something to look at adding for 2.6 to get ready for the database overhaul in 2.8/3.0. It's not in 2.4, and it would need a new "feature" table to hold the features so it probably shouldn't go in. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
