kicad-developers team mailing list archive

[David Godfrey <info@xxxxxxxxxxx>]

Hi Wayne,

Nice concise response and good direction, exactly what is needed from a
Project Leader.

Regards
David G

On 12/04/16 07:32, Wayne Stambaugh wrote:
> I'm going to put on my project leader hat and try to respond to all of
> the issues discussed thus far rather than reply to each concern
> individually.  I'll start off by saying that many of you are going to
> disagree with me but I'm OK with that.  At the end of the day, I'm
> responsible for the code that ends up in KiCad so my opinion counts just
> a little so here it goes.
>
> As for providing the ability to save older file versions, I have very
> little interest in asking any of our developers to provide this given
> the project's limited manpower.  Comparing KiCad to LibreOffice shows a
> lack of understanding in just how few developers contribute to KiCad.
> There are many paid full time developers working on LO, and hundreds of
> volunteers.  KiCad has two very part time paid developers, a couple of
> regular contributors, and a handful of occasional contributors.  This
> does not mean that I do not care about our users.  On the contrary, I
> prefer to use our limited manpower resources to get the most bang for
> our buck.  I believe we have much bigger issues to resolve than being
> able to save to old file formats.
>
> Any changes to the file format, parser, and output formatter will be
> heavily scrutinized to ensure they meet the following criteria: the file
> format must be human readable without being overly verbose and the file
> parser and output formatter code must well designed, easy to understand,
> and easy to extend.  Everything I have seen discussed thus far runs
> counter to these design goals.  I am not saying that I will not allow
> any changes but these design goals are in play.  This means you should
> assume that the bar is going to be very high for any changes to this
> code and/or the file format.
>
> That being said, we should attempt to provide some type of file version
> information to help the user figure out what to do when they have file
> version issues so I propose we do the follow:
>
> * Use Chris' time stamp version number patch.
>
> * Allow the file to be parsed as is.
>
> * If the file fails to parse and the file header information is valid
> use the version number to determine if the file is corrupt (<= build
> file version) or the file may have failed because it contains features
> not available ( > build file version).
>
> * If the header was not successfully read, warn the user that the file
> does not appear to be a kicad board file.  If the file does parse
> successfully and the file version is > than the current build version,
> warn the user that the file was created with a newer version of KiCad
> which may result in data corruption and/or loss and see if they want to
> continue.
>
> * If the file version is <= the build file version than all is well.
> This should cover most of the file parsing cases and give the user some
> useful information on what steps they may or may not want to take to
> resolve their file version issues.
>
> This may not satisfy everyone's goal but it's far better than what we
> are doing currently without making a mess of our file format, parser,
> and output formatter.
>
> Cheers,
>
> Wayne
>
>
> On 4/11/2016 12:00 AM, David Godfrey wrote:
>> Hi All,
>>
>> On 11/04/16 07:37, Wayne Stambaugh wrote:
>>> Let's slow down and think about this a bit.  I'm not sure that this is
>>> the best way to resolve this.  Let me chew on it a bit and I will get
>>> back to you.  I've been busy today so hopefully by tomorrow I'll have an
>>> answer.
>> Wayne,
>> Off the cuff I'd propose a single "used features" block in the file format.
>> This would purely be a list of features that are used by this file. then
>> it's easy for the loading software to confirm what it supports
>> eg: roundrect-1, angletext-33
>> the appended number can be used to differentiate between non backwards
>> compatible versions of a feature
>>
>> This would be fairly easy to implement, and trivial to test at file load
>> The hardest part would be spending the time to go through and define the
>> struct to the project that records every feature we care about.
>> Although that could be done by only adding features to that struct when
>> a change is made from now on.
>>
>> Regards
>> David G
>>> Thanks,
>>>
>>> Wayne
>>>
>>> On 4/10/2016 12:36 PM, jp charras wrote:
>>>> Le 10/04/2016 16:11, Chris Pavlina a écrit :
>>>>> I like the idea. It'll take some work to implement properly, though. I can
>>>>> start working on it, but it will likely be at least a week before I have
>>>>> anything.
>>>> Thanks you to make me very happy ...
>>>>
>>>>> On Sun, Apr 10, 2016 at 04:05:42PM +0200, jp charras wrote:
>>>>>> Le 10/04/2016 15:31, Chris Pavlina a écrit :
>>>>>>> So - would you be happy with me just changing that to a warning that can be
>>>>>>> clicked through instead of an error, and rewriting the message a bit to agree?
>>>>>>>
>>>>>> I'll be more happy.
>>>>>>
>>>>>> But I'll be really very happy if a dynamic version numbering is also added, rather a fixed arbitrary
>>>>>> number.
>>>>>>
>>>>>> Currently the version is 4.
>>>>>> If a method is added (something like GetMinimalVersionNumber()) to all board items (tracks, texts
>>>>>> footprints, pads...), each item can return the needed minimal version to be read in file.
>>>>>> Currently they could return 4, but for a pad, if its type is rounded rect it will return 20160410,
>>>>>> and therefore its footprint parent returns 20160410 (or 4 if no rounded rect pad is found)
>>>>>>
>>>>>> Before writing the file, just run BOARD::GetMinimalVersionNumber() to know the actual needed version.
>>>>>>
>>>>>> -- 
>>>>>> Jean-Pierre CHARRAS
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> 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
>