EEVblog Electronics Community Forum
Electronics => PCB/EDA/CAD => KiCad => Topic started by: hpw on May 15, 2023, 05:25:07 pm
-
Read on...
https://groups.google.com/a/kicad.org/g/devlist/c/Qr6G7MMSgVo (https://groups.google.com/a/kicad.org/g/devlist/c/Qr6G7MMSgVo)
-
Good to know, I had seen it in gitlab and built it. Good thing I'm not using v7 yet for anything serious, just minor testing for now.
-
Good to know, I had seen it in gitlab and built it. Good thing I'm not using v7 yet for anything serious, just minor testing for now.
The real thing is, as given on the 7.0.4 milestone sheet as Jun 19, 2023
https://gitlab.com/groups/kicad/-/milestones/26#tab-issues (https://gitlab.com/groups/kicad/-/milestones/26#tab-issues)
:phew:
-
7.0.4 source has been released, but no announcement yet.
-
Anyway, they reduced with a bunch of issues to 7.0.5 as reduced bug fixing for the 7.0.4 and asked on the other main forum for testing.
In other words, a lot of issues are for 7.0.5 scheduled and as times allow also fixed...
So to wait or not I am not in hurry to start my projects. I did mostly for education purposes as each CAD tool with different behaviors to learn at first O;)
-
Apparently 7.0.4 will never be either. The next official release is now said to be 7.0.5, until that it's 7.0.2.
The weird part is that we now have 2 "releases" (7.0.3 and 7.0.4) in gitlab that aren't releases. I think the tags should change, but I'm not the one who decides.
And I'm not blaming for the hiccups, I know that it's been a lot of work for the developers.
-
Yes, things went :phew: ... 7.0.3 & 7.0.4 as only view gotchas fixes, as may they relates to same code .... and requires deep testing.
and finally almost al remaining went to 7.0.6 milestone.
Hopefully we get finally any better ... but only 7.0.6 and after. If the milestones do not get any changes.
Hp
-
7.1.0 may be a safer bet for the next release?
-
Is this why my software updater wants me to downgrade 7.0.3 to 7.0.2? Running as a flatpak. I've been ignoring it and waiting for it to go away.
-
Is this why my software updater wants me to downgrade 7.0.3 to 7.0.2? Running as a flatpak. I've been ignoring it and waiting for it to go away.
Yes.
-
I downloaded V7.05 this morning from the CERN stable directory. There has still not been an official announcement or mention on the KiCad forum. A few of the features from the nightly version have been included as well.
-
Is this why my software updater wants me to downgrade 7.0.3 to 7.0.2? Running as a flatpak. I've been ignoring it and waiting for it to go away.
Yes.
Well, I ended up doing the "downgrade" because it had also been updating KiCad symbol and model libraries.
Turns out downgrading it to 7.0.2 updated it to 7.0.5.
So, lol.
-
The 7.0.5 release announcement: https://www.kicad.org/blog/2023/05/KiCad-7.0.5-Release/ (https://www.kicad.org/blog/2023/05/KiCad-7.0.5-Release/)
I'm already using 7.0.5 in Fedora from the copr repository, but it will soon be available in official Fedora repository (currently in testing).
-
Well, again not to roast developers here as it's not doubt been a lot of work, but just as a user, it doesn't quite look like v7 is ready yet for professional use. Still too many bugs and hiccups. IMO anyway.
But they need as many testers as possible, so that's a bit of a catch-22. If the pro users wait and wait, v7 will never get to the level it should be at. So, I dunno.
In any case, like I'm sure many others, I'm still using v6 for work. And I find it unfortunate that most Linux distros have directly switched to v7 as a "rolling update". I think they should provide at least a separate v6 package. Right now, they don't seem to? So you have to build it yourself. Or use a flatpak or whatever. I think a "kicad6" package, that can be installed alongside v7, using the package manager (instead of tricks) would be a nice to have. Just a thought.
-
Well, again not to roast developers here as it's not doubt been a lot of work, but just as a user, it doesn't quite look like v7 is ready yet for professional use. Still too many bugs and hiccups. IMO anyway.
But they need as many testers as possible, so that's a bit of a catch-22. If the pro users wait and wait, v7 will never get to the level it should be at. So, I dunno.
In any case, like I'm sure many others, I'm still using v6 for work. And I find it unfortunate that most Linux distros have directly switched to v7 as a "rolling update". I think they should provide at least a separate v6 package. Right now, they don't seem to? So you have to build it yourself. Or use a flatpak or whatever. I think a "kicad6" package, that can be installed alongside v7, using the package manager (instead of tricks) would be a nice to have. Just a thought.
Linux has this headache of not allowing bundled libraries, and all libraries are part of the distro. That causes problems trying to say have kicad6 and kicad7 at the same time when one requires a older distro library that does not exist on the distro you are trying to use. Distro maintainers (not kicad) could opt to patch kicad to do that, but they won't. There are also Linux specific conflicts that occur due to Linux beliefs/behaviors on install locations
This is why concurrent installs is only easily doable on Windows and macOS where KiCad includes all of its dependencies are self-contained.
FlatPak also has a obsession deleting out old versions, I think anyway
The whole Linux ecosystem is generally hostile to concurrent versioned apps.
-
The whole Linux ecosystem is generally hostile to concurrent versioned apps.
Yes and no.
It's not like distros automatically package random applications automatically. Usually the initiative to ask to include some software in a distribution is made by either the software project itself or people that have interest in the project. _They_ decide which version to package and propose to the distribution. Of course, it's easiest to always take the latest version. But there is nothing preventing them (either the origin project, such as KiCad, or the package maintainer) to also create and maintain a package of an older version of the software. There are examples of this in Linux distributions (what comes to mind are e.g. iperf2 and iperf3).
But it causes of course more work for the original project and/or the package maintainer. They have to ensure that also the older version works with newer libraries. At the same time they could also patch security vulnerabilities in the older version, if they are responsible and have such a process in place. In my opinion this at the same time ensures higher quality of the software than the Windows model, where you can take any old garbage and install it in the system.
-
Well, it's probably problematic in some specific cases, but for KiCad, it doesn't seem to be too much of a headache.
I'm on Arch and so had to build KiCad v6 myself. I had no particular issues once I figured out the right options to pass to CMake.
Of course you need to use a different "prefix" than default for installing it then, and run from there. But KiCad uses different directory names for the user settings, so there isn't any clash from that POV.
This is the most "problematic" part on Linux in general, as it installs everything by default in the same location.