Library management - forward compatibility

Hi all,

how do you deal with maintaining own libraries over version boundaries?

  1. Do you keep old libraries, IOW duplicate your libs with every new KiCad version?
  2. Does every KiCad version break forward compatibility or are there versions with forward compatible library formats?

You can Use Git to version-control your libraries. Use tags or branches for each KiCad version.

When changing versions I just spend some time to open and save all my libraries (symbol and footprints).

My question targets the scenario of using different KiCad versions concurrently

Why?

If there is only a slight change to be done in an old product, e.g. because a component is no more available and the replacement has a different footprint, I just want to change this component. Migrating the project to a new KiCad version has the risk of unwanted changes, therefore I usually stay with the KiCad version the board was made with.

Therefore I need to access the different library versions at any time in the file tree. Switching between branches wouldn’t be the right way.

I intend to use directory names indicating the KiCad version, e.g. v8/symbols v8/footprints v8/packages3d v9/symbols v9/footprints v9/packages3d etc.

Any other suggestions?

You have to get back to some project after several years. I’m too old to be able to work with several versions at the same time. When I switch to new version I simply don’t remember what have to be done differently with older versions. When I learned how to make documentation with V8 I don’t want to get back to doing it in V5 (was much more complicated).
First revisions of my KiCad PCBs were done with V5. All of them that I expect be redesigned ever I just open and save when new KiCad version is released. It takes me about 2 hours and I have all potentially interested PCB in current version.
I also assume that each version have certainly no problems with opening previous version files. But with older versions - who can be sure.

As you have asked for the personal workflow:

  • this is valid fo my personal as well os for the setup of my company (small business, only few people)
  • I have installed the actual kicad version v9 and one older version (v8) in parallel
  • on at least one backup-system there are all older kicad versions installed (as insurance in case a actual kicad refuses to open a older design)
  • I keep all old libraries on the system
  • for the next kicad version I duplicate the library folders and change the kicad environment path variables accordingly
  • from that point on we work with the new version (kicad+library), all changes made to older libraries are then not automatically ported to the new version
  • the actual kicad standard libraries are not used, instead the kicad standard libraries from the first kicad usage (v6) are dragged along with this procedure. But we tend anyway to our own symbol/footprint libraries, so this is no real drawback.
  • no git (and other modern tools) are used, this workflow relies on copying folders and standalone merging tools (Winmerge) for sorting out file discrepancies. So maybe not the best role model, but for us it’s working good enough

It is best to migrate your “active” version of KiCad and all your libraries at the same time. If we need to go back and update a design that was made in an older version, we take the time to update it to the current version of KiCad as part of that process.

If you want to avoid that, I would recommend keeping your libraries up to date regardless. Assuming you are on Windows or macOS, you will have the old version of the KiCad built-in libraries in your old version of KiCad; you will just need to remove your personal libraries from the old versions of KiCad once you update those to the new format. So, if you do this, and you then go and edit a board in an old version, if you need to place a symbol or footprint that is not already on the board and not in the KiCad standard libraries, you can make a project-specific library in the old format and add the required symbol or footprint there. But from my point of view this is more work and hassle than just migrating the design to the latest version of KiCad.

1 Like

Since I intend to keep my latest “personal” V8 library tree, and I have a clean library management (path variables), I see no additional work here. If I need a modified footprint, I do it in V8, and when ready, I copy the .kicad_mod file to the V9 library tree (and maybe edit the 3D model path).

I don’t know how clean and thorough the migration of projects is in KiCad is, but from my decades of experience with all kinds of software, I’m cautious.

A migration would require a thorough comparison of Gerber outputs to be sure, this takes also some time.

As stated above: I would stick with the old environment only for minor changes.

Imagine in 2030 you will have V8,V9,V10,V11,V12,V13,V14.

1 Like

Just wondering: Can the database driven library system interface with multiple KiCad versions concurrently?