kicad-developers team mailing list archive

[Seth Hillbrand <seth@xxxxxxxxxxxxx>]

Am 2019-02-22 09:29, schrieb Wayne Stambaugh:
> > 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.

Hi Wayne-

It should be easier for new features as they don't need the wrap the 
parsing in versioning checks; especially for semantic changes.  It may 
be more effort when changing underlying structures that are shared 
between parsers.

I wanted to broach the subject before small changes are made to the file 
format to make it easier when we introduce the larger changes (such as 
DRC). Otherwise the parser will start to look like a spaghetti pile as 
it has branches for tags that are not relevant in v6 (or even v5).

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

My current thinking would be to support best-effort conversion similar 
to the Eagle import.  This means that new pad shapes might change, fill 
types (like JP's hash fill) might change but any features in the board 
that existed in v5 could remain the same.  There would be an explicit 
warning about the file export and I'd document the expected outcomes for 
features.

_S