kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 8/15/2016 10:30 AM, Maciej Sumiński wrote:
> On 08/12/2016 05:57 PM, Chris Pavlina wrote:
>> On Fri, Aug 12, 2016 at 05:18:57PM +0200, Maciej Sumiński wrote:
>>> There is a set of patches for the PNS router [1] coded by Tom that we
>>> would like to commit soon (a few teasers: locking tracks & vias,
>>> removing tracks while the router is active, 45-degree tuning meanders).
>>>
>>> One of the changes adds a possibility to specify differential pairs
>>> width & gap per net class and stores the information in .kicad_pcb file.
>>>
>>> As there is a file format change, we need to bump the file format
>>> revision. I believe it would be better to do so for a bigger change set,
>>
>> Why? I'd bump the format revision once for every new added feature, and
>> add features once per commit. What does lumping them together gain us?
>>
>>> hence the question: does anyone have modifications to the .kicad_pcb
>>> file format stashed? If so, it might be the right time to apply them.
>>>
>>> Regards,
>>> Orson
>>>
>>> 1.
>>> https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ref/tom-pns-aug05-rebased
> 
> I am trying to avoid a situation when we get bug reports with bazillion
> different file formats. We have already got a few bug reports regarding
> rounded rectangle pads that are supported in nightlies, but not in
> 4.0.3-stable.
> 
> Committing file format changes in bulk means fewer revisions, and as
> such should be easier to handle. Especially if KiCad testers share their
> design files, which is a common case.
> 
> If there are no objections or foreseen file format changes, I would like
> to merge the branch this week.
> 
> Regards,
> Orson

Orson,

Go ahead an merge this.  In the short term, we can bump the rev for each
change and see how it goes.  If it becomes problematic, we can readdress
it then.  I don't want this to slow down development.  I will say up
front, failing to update the revision when making file format changes is
a shooting offense.  I am having a hell of time with the component
library parser because of this very reason.  Let's not repeat that with
the board and/or footprint library file formats.

Thanks,

Wayne