On 5/10/2016 2:17 PM, Chris Pavlina wrote: > I don't think there is anything that can be done about that. If the file was > made by a later version, there's no way I can think of to distinguish a true > error from a new feature. Personally, I think the combination of (later > version > + new feature) is much more likely than (later version + file error) anyway.
I agree. I was just playing devil's advocate. I can already hear a user complaining after upgrading kicad did not solve their file parsing error. > > I'm going to merge the patch as is; if someone can think of a better way to > phrase the error message we can easily update the string in another commit. > > Thanks for taking the time to test it. :) > > On Tue, May 10, 2016 at 02:01:47PM -0400, Wayne Stambaugh wrote: >> Chris, >> >> I finally got a chance to test this patch. I couldn't find any issues >> with it. The only thing that could be confusing to the user is if the >> board parser fails for a legitimate error, recommending an upgrade may >> be misleading. I'm not sure there is much you can do about that. If >> it's ready to go then go ahead and commit it so we can get some wider >> testing before I merge it into the stable branch. >> >> Thanks >> >> Wayne >> >> >> On 5/1/2016 6:59 PM, Chris Pavlina wrote: >>> Followed up on this question in a separate mail. >>> >>> Patch is attached. Please have a good look over it, if it's going to stable >>> I >>> don't want to be the only one who's had a look :) >>> >>> On Sat, Apr 30, 2016 at 07:57:36PM -0400, Chris Pavlina wrote: >>>> I'm very close to finished - I'll take some time to fully test and review >>>> the >>>> patch to ensure it's ready for a commit to stable, though - will submit >>>> tomorrow. >>>> >>>> I have a question. Currently, when loading a full library as opposed to a >>>> single footprint, we silently ignore errors and just do not load footprints >>>> that have syntax issues. This of course means that format versioning won't >>>> really work for these. The user will never see the hint about their version >>>> being old. >>>> >>>> Should I: >>>> 1) Leave it as is. (please say no please say no please say no) >>>> 2) Make an exception for the version-too-new case. >>>> 3) Change this and *do* display these errors, in all cases. >>>> >>>> On Fri, Apr 29, 2016 at 09:24:19AM -0400, Wayne Stambaugh wrote: >>>>> Thanks for the update. I've been holding off on releasing 4.0.3 for >>>>> this. I apologize for my absence over the last week or so. I've been >>>>> really busy at work and got sick on top of that so my motivation to >>>>> spend what little free time I had working on KiCad was low. >>>>> >>>>> Cheers, >>>>> >>>>> Wayne >>>>> >>>>> On 4/28/2016 2:38 PM, Chris Pavlina wrote: >>>>>> Just a quick ping to reassure y'all I'm still working on this - been >>>>>> caught >>>>>> up in other things a bit the last couple weeks. I've got a nearly working >>>>>> implementation here. >>>>>> >>>>>> On Tue, Apr 12, 2016 at 12:22:48PM -0400, Wayne Stambaugh wrote: >>>>>>> I doubt this going to be a big issue. Since the new board file format >>>>>>> was implemented over fours years ago there have been a handful of >>>>>>> changes. I think we're going to be OK with just the date code. >>>>>>> >>>>>>> On 4/12/2016 12:06 PM, Chris Pavlina wrote: >>>>>>>> Let's just not do more than one format change in a single day... I >>>>>>>> think that >>>>>>>> would be a beneficial decision for project stability as well... >>>>>>>> >>>>>>>> On Tue, Apr 12, 2016 at 05:26:27PM +0200, Timofonic wrote: >>>>>>>>> Despite my very limited knowledge, I like the simple approach. >>>>>>>>> >>>>>>>>> What about using letters if more than one format change is done? >>>>>>>>> >>>>>>>>> 20160412A, 20160412B, 20160412C... >>>>>>>>> >>>>>>>>> On April 12, 2016 2:30:23 PM CEST, Chris Pavlina >>>>>>>>> <[email protected]> wrote: >>>>>>>>>> Honestly I don't see the advantage to using Semantic Versioning for >>>>>>>>>> an >>>>>>>>>> internal file format version... and using 2016.04.12 instead of >>>>>>>>>> 20160412 >>>>>>>>>> just seems like an exercise in making the parser more complicated. >>>>>>>>>> Could >>>>>>>>>> you explain *why* this would be a good thing? >>>>>>>>>> On Apr 12, 2016 1:51 AM, "David Cary" <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Please at least consider Semantic Versioning ( http://semver.org/ ). >>>>>>>>>>> And I recommend that if you figure out any way to improve on SemVer, >>>>>>>>>>> please speak up so maybe the next version of SemVer can incorporate >>>>>>>>>>> those improvements. >>>>>>>>>>> >>>>>>>>>>> I have enjoyed the discussion of new features and various ideas for >>>>>>>>>>> versioning, and I encourage you to discuss them further. >>>>>>>>>>> >>>>>>>>>>> I am happy that the native KiCad file formats already avoid many >>>>>>>>>>> problems mentioned in >>>>>>>>>>> "Designing File Formats" >>>>>>>>>>> http://www.fadden.com/tech/file-formats.html >>>>>>>>>>> . >>>>>>>>>>> Are there any remaining recommendations in that essay that maybe we >>>>>>>>>>> should include in future versions of KiCad file formats? >>>>>>>>>>> >>>>>>>>>>> If hypothetically we did use Semantic Versioning, >>>>>>>>>>> would it be better to do (a) or (b)?: >>>>>>>>>>> (a) have a single KiCad version number that KiCad writes into every >>>>>>>>>>> new file it creates, or >>>>>>>>>>> (b) have a separate and independent version number for each part of >>>>>>>>>>> KiCad -- the Eeschema version number written into new schematic >>>>>>>>>> files, >>>>>>>>>>> a separate Pcbnew version number written into new footprint and PCB >>>>>>>>>>> layout files, etc. >>>>>>>>>>> >>>>>>>>>>> (How many independent version numbers could option (b) require?) >>>>>>>>>>> >>>>>>>>>>> On Thu, Apr 7, 2016 at 1:04 PM, Chris Pavlina >>>>>>>>>> <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>>> What about using the date the change was made as a "version >>>>>>>>>> number"? Can >>>>>>>>>>>> integerize it like 20160407 for example. This allows easy >>>>>>>>>>> cross-referencing of >>>>>>>>>>>> a format version with the revision that it was made in, and is >>>>>>>>>>> guaranteed to >>>>>>>>>>>> increase monotonically if you use a YMD format :) >>>>>>>>>>> >>>>>>>>>>> I agree with Wayne that it's more meaningful than most version >>>>>>>>>> strings. >>>>>>>>>>> >>>>>>>>>>> My understanding is that "integerized date" without punctuation is >>>>>>>>>>> more commonly known as the "ISO 8601 date basic format". >>>>>>>>>>> >>>>>>>>>>> Recently I've been putting a date like that on the silkscreen of my >>>>>>>>>>> PCBs. (I use the "ISO 8601 date extended format" like 2016-04-07, >>>>>>>>>>> the >>>>>>>>>>> format produced by the KiCad "%D" format symbol). >>>>>>>>>>> >>>>>>>>>>> Is it possible to combine that with Semantic versioning, getting >>>>>>>>>>> something like 2016.04.07 ? >>>>>>>>>>> (This assumes we won't make a breaking change in the file format >>>>>>>>>>> more >>>>>>>>>>> than once a year -- optimistic? :-) >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> David Cary >>>>>>>>>>> +1(918)813-2279 >>>>>>>>>>> http://OpenCircuits.com/ >>>>>>>>>>> http://david.carybros.com/ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>>> Post to : [email protected] >>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Enviado desde mi dispositivo Android con K-9 Mail. Por favor disculpa >>>>>>>>> mi brevedad. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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
