The downloads page only shows 4.0.7, not any version of 5. Is there a different stream of downloads for 5 in another location, or is it just not ready yet?
I have used several incarnations of KiCad already, but want to settle down with a stable release under Ubuntu, and work on libraries, for that reason, using 4.0.7 is not good for me due to the fundamental library incompatibility going forward.
any guidance is appreciated, I am very keen to have a new version up and running.
many thanks,
It’s not ready yet; you can use the nightly builds but they are not yet ready to be released as 5.0. Feature-wise they are quite close, and they are pretty stable already. Everyone here waits for 5.0RC1 more than anything. Hopefully it’s a couple of weeks away. Not everyone is so optimistic about that, however.
I guess waiting is the best plan, but I hope a workable version 5 is possible soon. It would be great to have a version that works correctly with the new libraries even if some new features aren’t ready, what we have is already pretty amazing. Everybody seems keen to move on to the newer structure and get past the library issues in 4, including me.
I certainly hope the issue of local or remote libraries is made clearer. in practice, over time everybody winds up using modified libraries, so a clear cut, simple user choice of doing that and protecting those libraries would be a huge leap forward.
I recommend building it from source and playing around with it for a while, if you have time. It’s not too difficult on Ubuntu. You can have and use it besides the stable package. Unfortunately nightly builds aren’t available as flatpaks or snaps (although you can install the stable version as f or s and a nightly build from the ubuntu ppa repository).
To be responsible I can’t recommend switching to nightly builds blindly, but I can say I use them at work successfully. Most of the most annoying bugs have been fixed and it doesn’t crash. Well, usually
You know there is a ppa for ubuntu nighlies right? https://kicad.org/download/ubuntu/
My suggestion for having multiple different versions to play around is to install them in different virtual machines.
Has there been an update to this? I currently run 4.0.7 (Debian Backports) but need the new addition of importing Eagle schems (about 200 projects I have done up).
I know I “could” compile from nightly however, that in itself present possible unforeseen issues when 5 is released. I have severed my yearly extortion payment to AutoCad (LOL) I do still have my 7.7.0 that used my older perpetual license. And with that, I am holding off working with Ki until I can fully use it.
Any insight would greatly be appreciated, please and thank you!
Not sure what you are asking. If you want to know a definite release date for kicad 5 then we need to disappoint you. Currently nobody can predict that.
If everything goes well wayne will make the rc1 tag this weekend. (rc1 will be a pre release. In no way is it a stable release.)
This means the first pre release will come soon. (After tagging there will be some time period for the packagers until the release will be officially announced.)
Understood - will the RC’s be publicly available? If so, might you know with there will be deb packages for Debian or might this still require compiling on my system?
As to the other bits of my ramblings, it was meant to simply show where I was was coming from and why.
I have been wanting to move to Ki from Eagle for a bit now. (more specifically when AutoCad introduced a yearly extortion, I mean, subscription fee for more than the basic functionality).
As a personal user of Eagle - it’s becoming more of an issue using it and being a Debian user, it seemed natural to go with a truly Open Source app. This prompted me to keep an eye on Ki over the past 12 months. When I read the blog about the introduction of the ability of Nightly to do a natural import if Eagle schems, I knew my time was coming to end for Eagle (gladly).
I found compiling relatively painless. I think I had to add a few things, but not much. Disclaimer, I’ve been using Linux since RH 5.2 and I don’t know what your comfort level is.
Indeed. I don’t run Windows so I don’t have the luxury of getting that nightly nor do I run Ubuntu.
Lets see what next week brings. As to compiling… to be honest, just plain lazy to go through all that, lol
I tried to install them side-by-side on the same machine and it didn’t work because of how the install maps fp-lib-table and whatnot. Is the virtual machine the only option, or is there a way to map the individual library tables to different locations? The fp-lib-table conflict was the only one I ran into, but I’m not sure if I would run into other issues along the way.
The problem for me is that, while I am fine using the nightlies until a release comes through, I collaborate on projects with others who are uncomfortable using nightlies. So I have to stick to 4.0.7/an old nightly in order to maintain compatibility with the other contributors.
How about setting up a virtual machine with Linux (probably Ubuntu or Mint) inside and using the PPA for the Nightly Builds? That’s how I keep my work desktop (Debian 9) at the stable version of KiCad and still can test the latest and greatest features.
With 200 EAGLE projects to import I’m sure there’s more than one that could help as a test case to help iron out bugs in the importer.
Setting up a vm is the safest and most flexible option.
The fp-lib-table is not the real problematic setup file. Nightly can use the libs that are used by stable. (The other way round is not possible.) There are other setup files that might create problems. (One per application) These are in the same folder as the global fp-lib-table.
At least in linux these setup files are in a user specific folder so you could simply have a user specific for nightly and one for stable.
Another option would be to have a startup script that copies around your setup files.
Or you find a portable build version of the stable release that has it’s setup files in a different folder than the default location for kicad. (I doubt there is such a portable version for nightly.)
The last option would be to change the locations of these files in the sourcecode and compile kicad your self.
Interesting. I never really considered a VM. I don’t think that would be very workable considering my lappy only sports 8 gig of ram. Perhaps its still something to consider.
I am curious to know what you used for the VM engine used in Debian.
When I wrote a standalone Eagle converter, I found a lot of weird cases where Eagle does things quite differently to Kicad, as well as mapping functions not available in KiCad. I wasn’t very familiar with Eagle before I started, so maybe the KiCad code handles it better. But I would expect there to be quite a few issues. Some things that cannot be converted to KiCad need alternative methods, so some post conversion tidying is often needed.
I didn’t find a good way to verify an Eagle project had converted correctly, apart from visual checking. Because the zone filling algorithm is different, comparing gerbers pixel by pixel generates a lot of false diffs.
I think a lot of potential new users are looking forward to migrating Eagle to KiCad, I think there are going to be a lot of support questions!
