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 <ke...@ve3syb.ca> wrote: >>>>> >>>>>> On 15 Apr 2019, at 13:56, easyw <ea...@katamail.com> 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@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
