kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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
>