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
