kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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 <pavlina.chris@xxxxxxxxx> 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+2012@xxxxxxxx> 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.chris@xxxxxxxxx>
>>>>>>>>> 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@xxxxxxxxxxxxxxxxxxx
>>>>>>>> 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@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>