I’m using nightly build versions of KiCad and last week I noticed that I wasn’t able to edit my existing symbol libraries anymore. All the changes that you make to your old symbols can be only saved in the new file format effectively forcing you to create a new library. There is no plan as of now to support import of your old libraries or support saving a symbol in the old format. So realistically the only option that you would have is to either start your symbol libraries from scratch or convert them manually one by one. That is if you are not satisfied with the standard KiCad symbols and want to keep the ones from your own library. Wayne doesn’t seem to think that such a change would be detrimental to existing KiCad users. So I figured I would gather some feedback from the real users. I started a bug report here about the issue .
No need to re-create.
Those libraries get automatically converted to a file with a new extension.
You need to add this changed file name to your lib list. That’s it.
I have not used nightlies so don’t have my own experience with the problem you describe - but i think i have a good inderstanding of it.
Just to give you a feel where i come from; I currently use 5.1.6 and do not use the kicad provided libraries. I have created my own, with my own folder structure, internal part number. When converting from 4.0.7, the converter made numerous mistakes so that i could not trust the end result - therefore i converted all i needed manually.
I am in a small tech startup right now, but used to work for a big mutinational. We switched Versions on our configuration management system at some point which also had changed its library structure. Keeping a copy of the old system next to the new was considered and ugly but acceptable option. Over time we migrated all parts and sub parts that needed to be available easily to the new system.
I am entirely comfortable with needing to keep a copy of 5.1.6 around for old projects. Part of progress is cutting away old stuff, although it sounds great to be able to read files in format versions from many generations ago, it is introducing a level of instability over time i would feel uncomfortable with. In my former job, we were required to read and write data and configuration files for a machine control system from 20 years back. Total nightmare! Keep in mind that a newer format introduces new capabilities which, when handling in the new software, need to be resolved somehow, preferably with smart default values and no endless conversion questions. In the long run that is just not practical.
Could a converter be build? Possibly/probably. Would i trust it? Depends, if i write it myself yes (i am not being arrogant, but in my work life i have lived through many data converters and few are ever flawless). I don’t want to write converters. Even if there was one available, i would eye it suspiciously and probably not use it. Saving the parts into a new library as is the kicad approach makes sense to me as it is then clear which is new and which not. But, i am going to test that conversion before trusting it - i would go dive into the data structure to understand how it is converted - so that i am not getting any surprises.
So i am happy kicad takes the “stay clean” route with the reasons stated above but also that our small dev team is better put to use on improving our kicad and not on spending time on compatibility issues. Though I would request that this is described very clearly and succinctly so noone stumbles into this by accident.
Not exactly. There is nothing automatic about it. Let’s say you have a couple hundred symbols in your personal library that you want to keep using. You will need to open every single one of them and save them to a new “library” - each symbol to it’s own file, i.e. it’s own library. Then you would have to create a new combined user library and import every single symbol one at a time again.
The conversion from v4 to v5 is very different from the conversion from v5 to v6.
Now we deal with a completely new format while v4 and v5 share the same format. So more caution is needed now. I must say in my case the conversion from v4 to v5 was flawless (or at least I have forgot any issue I mat had).
Understandable, I tend to be slightly OCD about my own libraries as well. Just a clarification question, when this change comes down the pipeline are you planning on manually redrawing each symbol from your personal library from scratch or you thinking about opening each symbol and then saving it, kind of what I described above. If it is the latter, then you are going to use a “converter” of sorts, albeit a very clumsy one.
If the process is similar to the one we underwent for the footprint conversion from v2013 (legacy) to v4 (pretty) it will be easier than you think.
I’m not really “thinking” anything. I’m describing the way it is right now in nightly builds and is going to be based on Wane’s description if nothing changes
Don’t know what I plan on doing - I should first get a bit of experience with a nightly to see it for myself. You are correct that a manual open/save is a clumsy converter and perhaps I do have to write a bit of code to either convert the libs myself or automate the open/save (with e.g. automator on the Mac). Manually redrawing everything is a waste of time and also error prone, so unlikely I will go that route.
Either way, I need a trustworthy process and am not sure which route and verification method(s) that will take yet. I have always liked the idea of a verification tool for symbols and footprints that would be capable of checking against the library standards and some sort of (I am very vague on this) symbol checker may be an opportunity to be included on this. Might just be a nice summer time intern job to get such tool started.
OK, Art.
I agree one symbol at a time is crazy. That’s the reason I think some automatic method should be found. I have a lot of personal libraries too.
I’d imagine that when V6 comes out there will be an option to do a batch conversion of symbols supplied by the KiCad team. Either as a standalone tool (makes more sense as this is a one time operation) or as a tool within KiCad suite. If not for users that at least for official KiCad library.
But I suspect that migrating the official library will be a bit of a catch 22 situation. Until there is a converter it will be tough to update symbols checking scripts. But these scripts would help catch issues with the converter.
Somebody transferred the whole official lib already and i really doubt they did it on a symbol by symbol basis. See https://github.com/KiCad/kicad-symbols/issues/2697
The beauty of KiCAD is everything is open. DIY. I have a script I used to use to convert mod to kicad_mod from command line (thankfully not needed so often anymore).
For what it’s worth, the dev team is aware that moving to the new symbol format is not as easy as it could be today, and we’re talking about possible solutions. It’s important to keep in mind that it may take a while for these solutions to appear, so please have patience. We are interested in the process of moving from V5 to V6 being as easy as possible by the time V6 is released, but in the meantime, those using nightly builds will have to understand that it takes time to build out these kinds of features.
I don’t have a problem with slow progress. However, with a change that profound you would think you would come up with those tools first, before you implement the change that affects everybody who is using nightlies. You don’t really have to merge unfinished solution. And if you want people to test it and provide feedback you need to do it in such a way so those people don’t become “nightly hostages”.
The point of getting the new format out early is to let people start playing with it to find any issues, and let developers start adding features that can’t be done (or can’t be done easily) in the old format.
Things like migration tools to make it easy to move libraries from V5 to V6 come later, when things are more stable.
This is not a good time to use nightlies for real work. We appreciate users who use nightlies to test things out, report bugs, etc. But, we have limited development resources, and we choose not to spend those resources on polishing every bit of a feature before it goes to a nightly: that is supposed to be the difference between nightlies and a stable release.
This is exactly what the KiCad development process is: we choose to sometimes merge unfinished things to nightlies, especially big things like an entirely new format, so that parts of those things can be tested while other parts are still in development.
Regarding “nightly hostages” – the way we have always recommended people test nightlies is to make copies of their data to test with: if you are working on a copy of your project and a copy of your libraries, you can always throw those copies away and go back to 5.1 to do “real” work with.
Be it as it may. With such philosophy you are going to have limited testing resources as well. People who are willing to use nighties don’t have very high level of expectations for things being “polished”. Just don’t bent us over the barrel of the gun and you won’t hear a single complain from us. All it takes is a little bit of thinking ahead.
I think your reaction here is a bit extreme. If you want to edit legacy symbol libs, use 5.1. If you want to convert your symbol libs to the new format, we’re going to make it faster to do that later.
You said in your original post “there is no plan to support import of your old libraries” – this is not true, that is our plan for how people will migrate to the new format.