Anyone knows whether the the 6.99 libraries are compatible with 6.0 ? Can I safely share libraries between 6.99 and 6.0 ?
In general, no. Once you start using 6.99 libraries you cannot go back to 6.0.
The caveat is: specific libraries may not have been updated yet, so you may get lucky, but it’s a gamble.
1 Like
Fair enough.
My idea was to migrate specific projects, but keep common libraries. It seems I will have to separate the libraries.
You can do this if you make sure to never modify the libraries in 6.99 (so, only edit them in 6.0, and only use them in 6.99 without ever editing/adding symbols/footprints) but there is no trivial way to have the computer guarantee that for you.
Are the library and schematic files still text based. Is the 6.99 and 7.0 versions basically the same structure as in version 6?
I have written software that reads and parses the version 6 files for specific purposes. I am wondering my existing code will still work on 6.99 or version 7 files.
Thanks for any insight on this.
Kevin
1 Like
They are definitely pure text based
1 Like
In particular, UTF-8 encoded.
There was a big file format change for the schematic and schematic library file format in the transition from KiCad V5 to V6. Now both the Schematic, PCB, and their libraries are based on S-expressions, and it seems unlikely this will change again anytime soon.
I guess that in the coming 10 years or so, there will mostly be small incremental changes as new functions get added to KiCad, and some of those need a file format extension to be able to get implemented. I’m not a KiCad developer though, and don’t know much about KiCad’s internals, so it is just a guess.
S-expressions have their data structured in nicely separated compartments. This would make it quite easy to have the file parser generate an overview of any added features it can not interpret. With such an addition you get an instant warning if there are file format changes. I am sort of hoping that at some time a form of forward compatibility will be built into KiCad, where it first flags the parts of the S-expressions that it does not understand, and then (gives you an option to) either discard that “extra” data, or just keep it where it is without being able to interpret it. Hopefully this would allow older KiCad versions to at least read most of newer KiCad versions, and when the data is kept, it won’t damage the file too much if it’s converted to a newer file format again.
But maybe this is a really bad idea, as it can lead to subtle errors in file format when it is saved in an older format.
1 Like
The switch to an annual release policy means that the incremental changes will be much less than V4 - V5 and V5 - V6
At the same time it makes it likely that some forwards compatibility becomes much more useful as different versions will overlap in time much more of the cycle
1 Like
The general format has stayed the same, but there may be new attributes and object types and maybe some other changes. But it should be no big problem adjusting your code.
1 Like
Thanks for all the replies on formats, very encouraging!! Happy Holidays!
Kevin
My advice is to use git for your projects and your libraries.
This way you can have a v5 branch of the library and keep compatibility with older projects while moving forward
This is essentially the scheme I run where each project is its own repo where I use tags for revisions and branches for kicad versions.
Something like gitea makes the git (private) hosting soo much easier
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.