My 2c: let the parser ignore unknown/incompatible s-expressions and warn the user when they are encountered.
On 14 January 2015 at 22:24, Martijn Kuipers <martijn.kuip...@gmail.com> wrote: > > On 14 Jan 2015, at 21:07, Cirilo Bernardo <cirilo.berna...@gmail.com> > wrote: > > > > On Thu, Jan 15, 2015 at 3:27 AM, Tomasz Wlostowski < > tomasz.wlostow...@cern.ch> wrote: > >> On 13.01.2015 20:11, Wayne Stambaugh wrote: >> > 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. >> > [snip] > >> OK, how about this: >> - No extra version tokens (fits point A) >> - Warning instead of error on unrecognized tokens (point C - no big >> changes needed in the parser) >> - If the opened file is produced by a newer version of Kicad, issue a >> big warning when the user attempts to save it, that certain features >> will be lost (points B and D - if somebody complains we can always tell >> him he was warned). AFAIK this is what most commercial software does. >> >> Cheers, >> Tom >> > > Except for Acrobat Reader, all the other software I use simply tells me it > cannot load the new file. In a corporate environment and especially on > large projects no one wants to take the risk that someone obliterated some > data. Let's say Person A sends Person B a file with data missing - what > can Person B possibly do with that now? Person B was never aware of the > warning that Person A ignored and the software is not psychic so it cannot > say "hey, the last time you worked on this file it was Version X.Z, not > X.Y". > The problem gets worse and more difficult to detect as the project gets > more complex. People need to understand the limitations of their tools and > work with that. As I said before people can negotiate what version they > need and if necessary build/install to support a specific project. > Otherwise > why use file versions at all if we're essentially only using it to tell if > there > are newer features and essentially ignore it and write corrupted data > anyway? > > > > I would be very happy with backward compatibility, especially if it would > allow us to safe the file in the older format. > This way, not everybody in the team needs to have the same version to be > able to work. > > Of course, if someone saves it in the new format, then I would not expect > an older kicad to be able to read it. > Wayne could even decide that every format-change implies a version number > increment, so we can tell the user to install kicad newer than version x.y > > I also think, this is not something that will happen every day, so we > should not overdesign this. Forward compatibility for a EDA tool is not > something I would advice, as there are just to many things that can go > wrong. > > If it makes things simples, an external file-format converter would also > be fine. > > Just my 2 cents, > Martijn > > > - Cirilo > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
