kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Hey Seth,

I'm not sure the added complexity of a subversion buys us anything over
just updating the file format version.  This particular change was a bit
of an odd ball in that it didn't break anything as far as the parser is
concerned.  I wish I would have quoted everything that is used a string
in the original file format so it was obvious what is a token (keyword)
and what is a string.  Hind sight is always 20/20.  I will not make that
mistake with the new schematic and symbol library file formats.

Wayne

On 5/16/19 8:47 AM, Seth Hillbrand wrote:
> Hi Wayne-
> 
> What about a "sub-version" tag?  KiCad can write it to the file but
> doesn't need to parse it.  We reset it to 0 with each file version
> update and then increment the subversion anytime we need to change the
> file formatting.  External parsers that care about formatting can use it.
> 
> -Seth
> 
> Am 2019-05-16 08:40, schrieb Wayne Stambaugh:
>> Rene,
>>
>> It's probably a bit late now but Jeff's assessment is correct.  I
>> understand your concern but technically this doesn't change the file
>> format when spaces are used in strings it just makes it obvious that the
>> information in the file is used as a string.  I'm not opposed to
>> changing the file version but I'm not sure it buys us anything.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 5/5/19 4:29 AM, Rene Pöschl wrote:
>>> Even if the current kicad versions can read it it still makes problems
>>> with version control.
>>>
>>> For that reason i would request a file format verion update on any
>>> change to the file generation at least for library assets as it has
>>> direct impact on the library maintainance!
>>> It makes it near to impossible to easily identify changes made by the
>>> contributor compared to changes made by the new file format algorithm.
>>>
>>> The reason for my report is:
>>> https://github.com/KiCad/kicad-footprints/pull/815/commits/624037c1ca388506fca4d1d5b6b42e9f68157470
>>>
>>> Now tell me which changes where made by the user on purpose and which
>>> where introduced by the algorithm change.
>>>
>>> I would simply suggest the following rule to be added to the release
>>> policy: Have a set of reference files. Save them without doing actual
>>> changes. If git detects a change in the resulting files than a file
>>> format change did happen and needs to be clearly indicated.
>>>
>>> On 21/04/19 18:46, Jeff Young wrote:
>>>> Hi Kevin,
>>>>
>>>> KiCad will read them in either way (quoted or un-quoted).
>>>>
>>>> KiCad has always written them out with quotes if they had spaces in
>>>> them (so other tools have always needed to handle quotes).
>>>>
>>>> We’re just being more consistent now as there’s no justification for
>>>> “saving a few characters” in this day and age (and going forward it
>>>> will make things easier).
>>>>
>>>> Cheers,
>>>> Jeff.
>>>>
>>>>
>>>>> On 21 Apr 2019, at 17:25, Kevin Cozens <kevin@xxxxxxxxx> wrote:
>>>>>
>>>>>> On 15 Apr 2019, at 13:56, easyw <easyw@xxxxxxxxxxxx> wrote:
>>>>>> recently I have noticed that both kicad_pcb and kicad_mod seems to
>>>>>> have changed their format.
>>>>>> It have been introduced double quotes for layers pads etc.
>>>>> [snip]
>>>>>> (layers
>>>>>>     (0 F.Cu signal)
>>>>>>     (31 B.Cu signal)
>>>>>>
>>>>>> (layers
>>>>>>     (0 "F.Cu" signal)
>>>>>>     (31 "B.Cu" signal)
>>>>> When I was asking about an updated file format document I was told
>>>>> "There have been virtually no changes to the file format other than
>>>>> how symbol library links are defined for a very long time."
>>>>>
>>>>> I consider it a file format change if quotes weren't needed before
>>>>> but they are now. It is the type of information I need to be sure I'm
>>>>> generating files in the proper format to avoid possibly having to go
>>>>> through the migration process.
>>>>>
>>>>> There may be other change(s) I may need to know about because the
>>>>> version number in the files has been bumped since the current file
>>>>> format doc was written. The files I'm generating are a version behind
>>>>> and have to go through a migration process when I try and open them.
>>>>> I don't fully trust the migration process.
>>>>>
>>>>> I hope someone can update the docs after KiCon, or perhaps someone
>>>>> can point me to which file(s) generate the schematic files used by
>>>>> eeschema.
>>>>>
>>>>> -- 
>>>>> Cheers!
>>>>>
>>>>> Kevin.
>>>>>
>>>>> http://www.ve3syb.ca/              ; | "Nerds make the shiny things
>>>>> that
>>>>> https://www.patreon.com/KevinCozens | distract the mouth-breathers,
>>>>> and
>>>>>                                     | that's why we're powerful"
>>>>> Owner of Elecraft K2 #2172          |
>>>>> #include <disclaimer/favourite>     |             --Chris Hardwick
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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