kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

On Fri, Dec 16, 2016 at 07:55:20AM -0500, Wayne Stambaugh wrote:
> On 12/16/2016 6:03 AM, Tomasz Wlostowski wrote:
> > On 15.12.2016 20:02, Chris Pavlina wrote:
> >> The addition of (diff_pair_gap) and (diff_pair_width) has made it such
> >> that NO PCBs made with 'master' builds can now be loaded in the 4.0
> >> branch. Would a patch be accepted to do one of the following, to be
> >> added to the 4.0 branch to ease future conversion from 4 to 5?
> >>
> >> 1. Fully backport saving diff pair dimensions to v4, but only write them
> >>    to the file if they already existed in it at load. This way, v4
> >>    writes files compatible with older v4 by default, but if editing a
> >>    v5 file will not lose the data.
> >>
> >> or:
> >> 2. Specifically ignore these options on load, since dropping them
> >>    doesn't actually lose any PCB objects.
> >>
> >> or:
> >> 3. Update the version number checker code I wrote before to have both
> >>    Warnings and Errors, using Warnings when ignoring the unknown object
> >>    and loading the board anyway will not lead to "important" data loss.
> >>    Add these attributes to a list of unknown objects that generate
> >>    Warnings.
> > 
> > How about adding an additional section in the .pcb/.sch files describing
> > all objects used together with required versions and their descriptions,
> > e.g:
> > 
> > (object-info
> > 
> > 	(object "diff_pair_gap" ( minimum_version 4 ) ( severity warning )
> > (message "This file contains differential pair gap settings that come
> > with XXXX version of Kicad. Older versions will not respect the defined
> > gap settings ) )
> > 
> > 	(object "fancy_geom_shape" ( minimum_version 12345 ) ( severity error )
> > 
> > )
> 
> I against polluting the board file format with this kind of information.
>  Any attempt to provide forward compatibility would require a complete
> change in the project philosophy.  We have always worked under the
> notion that backwards capability is a must.  Forward compatibility is
> something we would not provide due to the effort required to maintain
> it.  Given that KiCad has zero cost to the user, the need to provide
> forward compatibility is low.
> 
> As for the diff pair parameter issue, why not have an undefined value
> which doesn't get written unless it is set by the user.  If the user
> isn't using diff pairs, just don't write the diff pair parameter to the
> board file.  This should be simple and much easier to maintain.

I think that's acceptable. I'm not necessarily in favor of strict
forward compatiblity at all times, I just don't like that we took the
step of breaking ALL boards even if they don't use a feature.

I can make a patch to do that this weekend.

I'm not so much against listing version information for attributes, I
think it's a good step to take and has been proposed many times -
however what I really want here is something quick that can go into the
v4 branch so people aren't hit by this in the transition to v5. Tom's
suggestion is more complicated, and I'm not sure it's right for
backporting to v4. We could discuss implementing it in v5 going forward
for v6 though.

> 
> > 
> > Cheers,
> > Tom
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp