kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

This is a tricky issue that has been discussed before.  The general
consensus in the past has been not to support forward compatibility.  It
increases maintenance and complexity of the file parser for a minimal
net gain to the user.  My preference is to force users that want to
bleed on the edge to use nightly builds rather than try to maintain any
forward file compatibility.  I think you'll find that trying to provide
forward file format capability will quickly create a huge mess that will
be difficult to maintain.  Give our limited manpower, I would rather
that time be spent moving kicad forward.

I also don't like idea of creating special tokens just for version
compatibility.  I would like to keep the file format as readable as
possible.  My guess is that any version compatibility tokens will have
to reference the other objects in the file making the file less readable
which is something that I will be reluctant to support.

How do you plan to prevent data loss when editing newer files with older
versions of pcbnew?  You would have to store all of the unrecognized
tokens and then attempt to put them back where they belong in the file
if you allow older versions of pcbnew to modify newer file versions.  I
see this as being problematic at best.

One solution might be to ignore any unsupported tokens and warn the user
that there may (will?) be data loss if the board is modified and saved.
 Even this solution I think has a lot of potential pitfalls.  Make newer
files read only is also a possibility.

The only way I would support forward file compatibility is if there is:

a) no loss of file readability
b) no loss of user data
d) no unnecessary increase in the complexity of the file parser code.
c) no hoard of angry users who want to edit a new file version with and
older version of pcbnew.

It's generally easier to tell users if they want edit the latest file
formats to install the latest version of kicad.  Under normal
circumstances, only developers and users using nightly builds should be
using new file formats so I don't see this as a major problem.

I'm not saying under no circumstances that I would not support forward
file compatibility but someone would have to write some really
impressive code to pull it off and then convince me that this is the way
to go.


On 1/13/2015 1:20 PM, Tomasz Wlostowski wrote:
> Hi all,
> 
> During my work on diff pairs/matched length tools, I've encountered a
> rather tricky problem: as the diff pair gap specific to a particular
> pair of traces is stored nowhere, the shove algorithm will mess up DP
> coupling after saving and re-loading the board. Ergo: the DP gaps (and
> possibly other settings) need to be stored somewhere in .kicad_pcb
> files. Perhaps in a yet another s-expr token.
> 
> The problem is that adding any new token to the file format causes all
> precedent versions of pcbnew to drop an error attempting to load the
> file. I would propose two solutions to overcome this:
> - (a dumb one) if the version in the file header is newer than the
> version supported by the running application, issue warnings instead of
> fatal errors on unknown tokens,
> - (a bit smarter) enclose all optional tokens in a "minimum" version
> block ( min_version version_number ( optional_token ( ... ) ) ) that
> would be ignored if the application version < version_number.
> 
> I consider this modification quite important from the point of view of
> adding future features and the upcoming stable version: if we keep
> things as they are, adding any new feature will either make the files
> unreadable to the stable version or force us to support saving in
> multiple format versions.
> 
> Looking forward to your feedback,
> Tom
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>