kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx>]

----- Original Message -----
> From: John Beard <john.j.beard@xxxxxxxxx>
> To: Kicad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Cc: 
> Sent: Wednesday, May 7, 2014 4:28 AM
> Subject: [Kicad-developers] Forward-compatibility in s-expression formats
> 
> I think it would be a good idea to allow unknown fields in the
> s-expression formats so that an older KiCad doesn't choke on things it
> doesn't understand, and doesn't need to.
> 


I was thinking of the same sort of mechanism; after all, it's been done numerous times before (including for example the PostScript and PDF specifications).

> 
> Ignoring *every* unknown field might also not be the best idea, in case
> there is one day a field which an older KiCad can't understand, but
> should realise "no, this means I can't use this footprint". So 
> maybe
> also a "fp_version" field, which, if missing, is assumed to be 
> "1".
> Then, if a future footprint declares "(version 2)", because it knows 
> it
> contains features a version-1 KiCad will misinterpret, that version-1
> KiCad can say "sorry, I'm version 1, you need version 2 or 
> higher". In
> this case, it would be nicer to not set the version to 2 if you didn't
> need to, so version-1 KiCads can use the footprint.
> 


In general, future versions should always act correctly with data from a previous version. Allowing a future version to say "hey, I'm not going to read this older format because I use the key 'qwijibo' differently" just doesn't make sense. Bumping the file version each time new required features are added to KiCad is sensible; the implementation may be a bit tricky though if a number of features are introduced as patches over a number of weeks or months.

- Cirilo