kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Hey 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.

This seems like a lot of extra effort particularly for small incremental
changes which I'm guessing describes JP's changes.  In the past we have
just updated the board parser and formatter with each new feature with
relatively few issues.  For larger changes such as the new constraint
management system, this may make more sense.  I know it's not always
possible but I generally prefer the small incremental changes because
they are far more manageable.

> 
> 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

Unit tests are always a good thing.

> 
> Nice to haves (but not required):
> - Save-as function that allows downgrades with limited feature sets

Is the idea to keep the v6 parser/formatter separate until v6 is release
and then drop the v5 parser/formatter on release or keep the v5 forever
to allow save as to v5?  If it's the latter, how do you plan on
converting the v6 structures to v5 without breaking board designs?  It
seems like there is a lot of built in complexity with this concept but
maybe I'm not seeing the forest through the trees.

> 
> Do people have concerns with this idea?
> 
> -S