Op woensdag 7 december 2011 10:34:33 schreef Derek Atkins: > John Ralls <jra...@ceridwen.us> writes: > > 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. > > Luckily the features table is one that doesn't affect the rest of the > database, so we could add it in without breaking <=2.4.8; but yes, only > versions >= 2.4.9 would know to check it, so it wouldn't necessarily > help older versions. > To avoid confusion: You propose to add a features table for the upcoming 2.6 and backport it to 2.4.9. So all (stable) versions as of 2.4.9 know how to handle it.
Together with this, I presume we should bump the compat version parameter, so that older versions of GnuCash will not attempt to load data files with that depend on the features table ? I don't see another way to prevent unintended access to newer features by older versions. Does it have to be a complete feature table by the way ? Or is just adding a single number (like the minimum required gnucash version to open the data file) sufficient. I don't see how an older version otherwise would know what features to check in order to determine if it is still compatible. Another question: who will be implementing this ? I don't feel comfortable enough in either backend to do this. If it weren't for Alex' example, I would have quite some difficulty also to simply add a new data field. Geert _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
