Duh! Nevermind, I already replied to this. On 3/8/2019 3:40 PM, Wayne Stambaugh wrote: > Seth, > > On 2/21/2019 10:16 PM, Seth Hillbrand wrote: >> Am 2019-02-21 15:21, schrieb Wayne Stambaugh: >>> Since we are nearing the 5.1.0 release, I want to get an idea of what >>> major merges are ready to go once 5.1 is branched. I know Jon's netlist >>> code is ready to merge and I'm pretty sure that should be the first big >>> merge. Does anyone else have any major changes they want to merge as >>> soon as v6 starts? I would like to get an idea of what changes to >>> expect so we can avoid any serious merge chaos. Please let me know what >>> you have in the queue so I can get an idea of how we should proceed with >>> the merges. >> >> I know that JP has some updates for the pad corners and I have a patch >> set for unifying graphical items with track segments. But both of these >> are file format changes, so I'd like some thoughts on the following idea >> first: >> >> Once v6 is started, I'd like to freeze the v5 parsers and make a copy of >> the parsers for v6. This would mean that all new format features would >> be implemented in a separate parser while any changes to underlying >> structures would require updates in three parsers (legacy, v5 and v6). >> This will be an "of course" for eeschema because we are re-working the >> format to s-expr but I think that it also makes sense to hold a fixed >> copy of the v5 parser with all its warts. > > I'm not sure about this. It really hasn't been necessary in the past > because we have made small incremental changes as we've added new > features. AFAIR, the last parser issue went back to the malformed text > formatting bug which dated back the original implementation. Do we > really need to keep two separate versions of the file parser and are we > planning to do this for every new version? Seems like a lot of extra > work for little net gain. > >> >> Some requirements to do this: >> - unit tests that open v5 files and save to a known good v6 files >> - unit tests that load v5 files and compare expected data structures >> >> Nice to haves (but not required): >> - Save-as function that allows downgrades with limited feature sets > > I am not terribly thrilled about this idea. It would require polluting > the formatter with a bunch of file format conditional checks. Given > that the cost of upgrading to KiCad is $0, I don't see the manpower to > implement it and the potential code mess it will create is worth the > effort. Our policy up to this point has been not to do this. > >> >> Do people have concerns with this idea? >> >> -S
_______________________________________________ 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
