New data field for invoice object - Follow up

[Geert Janssens]

I've been silent for a while on this topic, because I was occupied with other 
matters.

I have followed the whole discussion and the suggestions made on adding a new 
data field or kvp. After digesting is for some time, let me post some personal 
conclusions for my current case:

* Clearly GnuCash' ability to deal with different data schema versions can use 
some improvements.

* There were some suggestions that Alex added some code to introduce version 
checking in the xml backend similar to what is available in the sql backend. 
But I didn't find that code in svn. Perhaps I overlooked, or perhaps this code 
was part of the patch for his num_entry field that never got applied. So as 
far as I can see there is currently no version checking in the xml backend.

* So with what we have now, adding a new field is pretty disruptive and I'm 
more inclined to go with a kvp.

* The drawback of the kvp is that older versions of GnuCash could open the 
data file, don't interpret the kvp and as a result do "bad things" with the 
data.

* I think though will not be that bad. For starters, as Graham already hinted, 
if you load a data file with credit notes with an older version of GnuCash, it 
will treat them as negative invoices. Payments on such invoice are the main 
problem.

* With the progress I've made so far on the credit notes feature, I believe it 
will be relatively easy to backport some business logic to the 2.4 branch to 
make that branch sufficiently aware of credit notes to not mess up. If I at 
the same time don't backport any user interfaces to this branch, we will have 
a GnuCash version that understands credit notes, but doesn't explicitly let 
the user handle them. Of course as credit notes are interpreted as negative 
invoices, the user could open one via Find invoice. I could add a restriction 
there to consider each negative invoice as read-only, so the user won't be 
able to edit the credit note in 2.4.x.

* In the long run, the complete data model will have to be revised. At that 
time, the kvp can become a true data field. With that, we will have one big 
data incompatibility break. I prefer that over having small breaks all the 
time.

Geert