Hey David, Thanks. Being concise is a matter of necessity. I don't have enough free time to write long responses and I don't want anyone on the development to have to guess what I'm thinking.
Cheers, Wayne On 4/11/2016 8:40 PM, David Godfrey wrote: > 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@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp >>>> >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp