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 : [email protected] >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
