I’m just trying to find out, what exactly we have to do, that we can run KiCad 4 and the upcoming KiCad 5 in parallel on one system, and how to deal with porting existing projects to KiCad 5.
What I’ve found out so far (please correct me, if I’m wrong):
Project Template
the kicad.pro file for V4 lists the used symbol libraries, which is prohibited for a V5 project, since this uses the sym-lib-table
Symbol Libraries
Different symbol libraries have to be used, since the upstream-libs from KiCad use version 2.3 and 2.4 (and newer in future), KiCad 4 only supports up to version 2.3 AFAIK. V5 uses the sym-lib-table, but this should be ignored by V4, right?
Footprint Libraries
Again different libraries have to be used, since KiCad 5 uses a new footprint format, which supports polygons and rounded rects as pad shapes. I couldn’t find any version string in a footprint definition file (*.kicad_mod). What happens if KiCad4 should load such a new footprint format?
3D Models
Since the new footprints link to new 3D models, also here we have to use separate libraries. A definitive problem of the old footprint libraries is, that they do not use an explicit environment variable as a path prefix, which seems to be incompatible with KiCad 5.
If a project is migrated from KiCad 4 to KiCad 5, all the 3D models have been gone in the 3D viewer. That’s really not acceptable. Is there any script available, which can fix the existing KiCad 4 footprint libs, by inserting a given environment variable?
Summary
All in all, I think it is doable, but the user has to manually switch the config folders. I would be very happy, if the path to the config folder for KiCad 5 is overridable by some way.
My suggestion woud be a subfolder in the ~/.config/kicad which is called kicad5-override. There should be at least these files: kicad_common, fp-lib-table and sym-lib-table. So if the folder kicad5-override exists in the config folder, these files are used by KiCad 5. This would be perfectly backward compatible with KiCad 4.
In these German articles, which are work in progress, I tried to provide a step by step instruction for a headach free transition from KiCad 4 to KiCad 5:
I think devs are still deciding best way to do it, and whether it is something that can be harmlessly slipped into v5 or must wait for v6.
Personally I think simplest thing to do is use a default of “kicad5”, keep “kicad” for v4. If kicad5 is empty, it can be copied from kicad if exists to migrate settings.
There has been discussion today in the dev mailing list beginning with this message: https://lists.launchpad.net/kicad-developers/msg35545.html. If Wayne pushes it in, XDG_CONFIG_HOME environment variable will be used on all platforms. In the mail thread there are some tips for using it. If it will be available I will write about it here after I have tested it on Windows.
The idea of using XDG_CONFIG_HOME on every platform was problematic (see the above mentioned mailing list thread for details). The latest suggestion by Wayne was to use KICAD_CONFIG_HOME which would override, if set, the default config directory on every platform. I tested the patch on Linux and it works. The HowTo instructions give details on how to use use v4 and v5 side by side with this new and other environment variables. It’s a work in progress and not tested yet. Please comment.
@eelik
Great, I like your guide and the progress from the developers on this topic. It seems to fit very good to my “Reference Card” I’m currently working on.
I also would like to get some comments about that. Original files are edited with Inkscape. Any interests on setting up a GitHub Repo for them?
The articles belonging to this reference card are still only in German language available on my private wiki, but for interested ones, googles translator does an acceptable job on them. For links, see original post above.
I tested the new KICAD_CONFIG_HOME and for the first time had both versions 4 and 5 running at the same time without sharing anything. This was how I did it:
Version 4.0.7 installed from jreynaud’s ubuntu repository
Self-compiled pre-v5, installed to the default /usr/local
Git cloned v5 libraries to /usr/local/share/kicad/libraries
Leave v4 as is
Write a bash script for launching v5
This is the script:
EDIT: WARNING: before this edit the first line had ‘~’ instead of ‘$HOME’, it was wrong and leads to kicad creating a directory named ~ which is not what we want.
Only the first export is necessary, the others are commented out in this example. If so, when the v5 is run for the first time I can set the paths in the project view dialog. Then they are saved into the used config so they don’t interfere with v4. Whether you set the library paths in exported variables or within KiCad is a matter of taste.
I marked the bug report as closed. I have tested the KICAD_CONFIG_HOME variable more thoroughly on Linux and fixed an issue in my document and in my previous post. Also some initial Win issues are fixed. Basically it looks like versions 4 and 5 can co-exist completely independently by using this variable. The easiest way to install them in my opinion is to install v4 with all defaults, including the libraries, and to install v5 and its libraries to another location and write a startup script for it. *-lib-tables can be copied from the v5 library directories to the v5 config directory (at least if the libraries are from the git repo). It’s actually easier to do it manually than to let the KiCad GUI help with it.
Thanks to the developers, they have taken this need for running multiple KiCad installs seriously. The latest news is about the templates path (see another thread by Karl, Default Project Template KiCad 4/5). Wayne posted in the developers mailing list today, proposing changes to the template finding code. See https://lists.launchpad.net/kicad-developers/msg35733.html.
BTW, the idea of recognizing XDG_CONFIG_HOME on all platforms came back and found its way to the code. I think the difference to the original situation when it was refused is that now users can use KICAD_CONFIG_HOME everywhere and there’s no need to set XDG_CONFIG_HOME except when one wants to use it in Linux etc. as a more global setting for several applications. They are not interchangeable nor identical.
