On 2/22/2010 1:16 PM, Derek Atkins wrote:
Geert Janssens<janssens-ge...@telenet.be> writes:
Note that schema updates don't depend on string freeze. HOWEVER you
need to consider forwards and backwards compatibility issues. For
example, we want files written by 2.4.x to be readable by e.g. 2.2.9.
I agree with that, and that the reports and UI should still function in
a "reasonable" way if you do downgrade. I've been thinking through some
ways of accomplishing this.
The addition of a way of denoting the "default budget" should be
reasonably easy.
Changing the internal storage of budgets seems like it might be best
left alone (save for copious documentation of the data-model
inconsistency), but the accessors (and associated UI and reports) be
modified for consistency with the rest of the app. 3rd-party reports and
extensions written for pre-2.4.x versions would work fine in pre-2.4.x
environments, but would likely need to be modified to respect the user's
UI-level sign-reversal preferences.
(As a side note, it becomes "rather challenging" to maintain backwards
compatibility when the backend is a database, especially if any columns
change or are deleted.)
How far back should I be confirming compatibility? 2.2.9? 2.2.0? Before?
Is there supposed to be guaranteed backward compatibility for anything
but the XML backend?
Does the XML backend "gracefully ignore" tags that it doesn't
understand? For example, if a "default budget" field is added to the
book, is it "skipped over" on read if there isn't a corresponding data
field for its contents to populate?
Can I assume that "backwards compatibility" allows for data that was
created in a later version, that did not exist in an earlier version,
not to "magically" be preserved if the user then moves forward in
version? For example, if 2.4.x adds "default budget" then the saves as
XML, opens in 2.2.9 (where the field does not exist), saves from 2.2.9,
then opens in 2.4.x, then the value of "default budget" would likely be
lost.
Thanks!
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
