r21577 - gnucash/trunk/src/backend/xml - Fix xml backend to load and save invoice kvp values.
Geert Janssens
janssens-geert at telenet.be
Wed Dec 7 11:15:32 EST 2011
Op woensdag 7 december 2011 10:34:33 schreef Derek Atkins:
> John Ralls <jralls at 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
More information about the gnucash-devel
mailing list