← Back to team overview

kicad-developers team mailing list archive

Re: V6 merge update

 

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


References