If Cirilo is right, I like that. "Why solve today what you can solve in the future?" :)
Adam Wolf On Tue, Jan 13, 2015 at 2:45 PM, Cirilo Bernardo <cirilo.berna...@gmail.com> wrote: > > On Wed, Jan 14, 2015 at 5:20 AM, Tomasz Wlostowski < > tomasz.wlostow...@cern.ch> 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 >> > > I would prefer to do what had been done in the past - simply increase > the File Version number and don't expect earlier versions to support > the new features (or to read the board at all). What we *can* safely > do is check the file version number when parsing and if the parser > does not recognize it then we can display a message to say that it > is a newer file version and we cannot read it. If people are collaborating > and this can be an issue then they must agree on a version of KiCad > to use; after all in most cases they can build any historical version > from the past 2 years. > > - 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