Chris, I'm not opposed to addressing this. I prefer option 3 but implementing that may prove to be a monumental undertaking given the current footprint loading code. This is something we should think about very carefully.
Cheers, Wayne On 4/30/2016 7:57 PM, 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 >>>>>> <pavlina.ch...@gmail.com> 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" <d.cary+2...@ieee.org> 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 >>>>>>> <pavlina.ch...@gmail.com> >>>>>>>> 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 : kicad-developers@lists.launchpad.net >>>>>>> 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 : 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
