I’m running Windows 10 and the current stable version of KiCAD (v4.0.7). I would like to have both the stable version and also a copy of certain nightly builds on this machine. The nightly builds would be for learning and familiarization, and the stable version for daily work.
I downloaded the latest nightly build this morning and when I ran the installer it prompted that it would overwrite my current stable version if I proceeded. There were no other install choices given such as installing KiCADV5 in another directory.
Is there a way that I can install both versions on my system? Also, would doing so cause any interference between the two versions? I don’t intend to share any projects between the two versions.
I haven’t tried this, but I would guess that the environment variables and global configuration would conflict. It would be easier to run one in a VM if that is easy for you to do. In theory one could make some kind of script to switch env variables etc. back and forth though.
Thanks for your response, Jon. I like your idea of running KiCAD in a VM. No messing around with environmental settings. After my post, I did install VMPlayer v14 and Linux Mint 18. I’m in the process of installing a nightly build right now. Will post the results of this experience later today.
I’ve been trying to get off the Windows platform for a while now. Most of my clients are still deeply committed to Windows. Will probably just set up an exclusive Linux box for KiCAD soon though.
The latest nightly open and ran without any problems.
KiCAD 5 looks really nice with all its enhancements.
Now the one small problem. When starting VMPlayer14 the error message comes up that VMAuthdServices failed. The solution turned out to be simple. As installed in the folder c:\Program Files, VMPlayer requires the VMPlayer.exe to run in Administrator mode.
One question about KiCAD v5… Is anyone using this version for their projects, or is it considered too risky yet?
I use V5 for everything but I’m also a developer so maybe not a fair data point
If you use a non-released version, it’s best to follow some precautions which I think are a good idea even if you don’t use a non-released version:
Always back up your designs and libraries.
The way I do that is by keeping my designs (and custom libraries) in a Git repository, so that even if I run a version of KiCad that completely messes up my files, I can just use Git to revery back to a working version.
In my experience, KiCad is quite stable now and much much nicer to use than 4.0.7.
I agree with craftyjon in about everything, except that I’m no a KiCad developer. Even 4.0.7 has bugs and undoubtedly new ones will be found. 5.0RC1 has more bugs and I would be amazed if no new crashes were found before the final release. But if you use git for your project and remember to save often you will be relatively safe. BTW, I learned the hard way what saving “often” means And recently there was one bug which made me to edit a board as text file, I was lucky the problem was found at all before sending to manufacturer. This can happen because the pace of development is high and the codebase didn’t have time to stabilize before RC1 was released (although my problems were pre-RC1).
So, if you can’t afford delays and problems, continue with 4.0.7. What is “too risky” is of course subjective and you have to decide yourself. I would encourage people to take a small risk and report new bugs; that way the product will be better. Even if you decide to switch only when the final is released it’s still possible you happen to be the one who finds some new bug.
Some of these problems will also affect the v5.0.0-RCx releases. (The libs for example will most definitely still change. The documentation is not yet done. …)
The main issue of using nightlies in production is that they are normally not guaranteed to produce files that can be opened by different versions. All files created by a release candidate should be compatible with the eventual version 5 release. (Unless a really bad bug has slipped through until now.)
Yes, I recommend backing up your config files if you are going to swap back from V5 and V4 on the same machine.
On Linux they are normally in ~/.config/kicad, on Mac ~/Library/Preferences/kicad, and on Windows in %APPDATA%\kicad.
If you back up your files before installing 5.0, you can revert to them later if you ever go back to 4.0. You don’t need to do anything if you are just upgrading from 4.x to 5.0.
Thanks all for your responses. Based on your comments I’ve decided to ZIP up my v4.07 and install a nightly build of V5 onto my Windoze machine.
One last question. Of the windows nightly builds, is there recommended a “best-of -the-current-nightly” version, or should I just go with last night’s build.
Now that we are post-RC1, each nightly has more bugfixes than the last, so I would “recommend” the latest (keeping in mind that the standard nightly disclaimer applies and it’s possible that they will have serious bugs, back up your files etc.)
With the benefit of hindsight, V5 should have used renamed configuration files. This would have allowed parallel installs.
Working on old projects with a Nightly is a few days of pain per project, the worst being the resetting of silkscreen text positions when I manually exchange footprints.
V5 is very stable now and if you look at the commits, I guess about 20% or more, are bugs that also exist in 4.0.7
Are there any published, comprehensive, lucid and articulate, guidelines for migrating from V4 to V5? It’s remarks like this that make me wonder if it’s ultimately less effort to maintain a dual installation, with V4 available for dealing with current projects and V5 used for everything from now on. But what do you do if a current project requires a significant change - do it in V4, or migrate the project to V5?
I appreciate that something like re-locating silkscreen strings is not a major concern in the scope of a complex software project, and rightly so. But as a user, re-locating the strings is tedious and a source of frustration. And it’s not something that springs to mind when somebody says, for example, “Moving from V4 to V5 is easy - ya just populate the new Sym_Lib_Table.”
I’m sure the silk screen is not the only example of a task that’s required in a V4-to-V5 migration, but not directly caused by the upgrade itself. Having all such tasks collected in a single location - or at least as many of them as we know of - would be a major help for planning purposes. Should I plan to convert all projects at once? Or break them into groups, completed over time? Or converted as-needed? And what about the project archives?
I assume that you also switched libraries. If so, this is a separate issue and is not strictly speaking migration from V4 to V5 issue. I find it is easier to keep used footprints and just use symbols from project-cache.lib if you really have to upgrade the project.
I agree V5 has features that are quite nice, the most important one is the handling of symbols. Also V5 library is way better than V4. so kudos to developers and library maintainers. But mainly due to library upgrade I found that it is way easier to keep V4 project where they are and use a VM with a V4 installation to edit old projects.
The major advantage that V5 RC1 has over 4.0.7 is stability now. I have 4.0.7 projects that were so prone to crashing that I used to save after every action.
