kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

>> Just keep those fields, that would allows the program to load ANY
>> legacy part without breaking the bank.

There is no bank.


> That's exactly what I mean - older versions of KiCad should be able to 
> ignore, but retain, unknown data.


This sentence has two concepts in it.  One is fools gold, the other is poorly expressed.

1) An older kicad should load a data file that is has never seen before.

2) You want flexibility within a certain realm of the s-expression grammar.  This is
possible, in the same way that kicad loads boards it has never seen before.  Each follows
a known grammar however.  The grammar allows for optional elements, and variable numbers
of the same element repeated within its parent.  It is not 'unknown data'.  It obeys the
grammar.

You are asking for a grammar change.  It is only *new* software that can support a new
grammar.  Once that support is in play, then you are not necessarily changing the grammar
just because you change a datafile, just like the board example above.  Within the SAX
model, you can extend the grammar at any time.  But it requires *new* software to support
that extension.

So there is nothing new here, we've been operating like this forever.  And achieving
backwards compatibility is also possible, as it has been all along.

The motivation should be that you want the flexibility to solve a specific problem.

But it should not name future proofing as the motivation, because you don't want to
upgrade.  That's the part that gives me conceptual grief.