On 15.01.2015 23:40, Miguel Ángel Ajo wrote: > I was talking about Altium in my previous email, and I believe > the points you made are quite reasonable (in favor and against). Hi Miguel,
Fully agree here. > > I also didn’t know about the measures of not saving the unchanged > defaults, which are quite neat. Me neither. Did anybody propose to *not* save settings that are considered default by the current version? What if these defaults need to be changed (for whatever reason)? > What about a flag in the loader parameters, disabled by default, but which > could be > used via scripting for extreme situations (recovery of broken files?). Dumping > warnings to stdout should be ok. Fine for me. Cheers, Tom > > > Miguel Ángel Ajo > > > On Thursday, 15 de January de 2015 at 21:37, Kaspar Emanuel wrote: > >> 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 >> (mailto:martijn.kuip...@gmail.com)> wrote: >>> >>>> On 14 Jan 2015, at 21:07, Cirilo Bernardo <cirilo.berna...@gmail.com >>>> (mailto:cirilo.berna...@gmail.com)> wrote: >>>> >>>> >>>> On Thu, Jan 15, 2015 at 3:27 AM, Tomasz Wlostowski >>>> <tomasz.wlostow...@cern.ch (mailto: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 >>>> (mailto: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 >>> (mailto: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 >> (mailto: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
