In fedora, the packaged version of KiCAD is typically one behind the current version, and if not so at the time when i get around to bringing fedora up to date, then sometime soon after.
There are two kinds of problems this generates.
If I file a bug report, it almost always gets bounced.
If I upgrade one computer and open a kicad project, it becomes unusable to other computers in my lab. So upgrades are an all or nothing proposition and extremely time consuming.
So there is a question and feature proposal
A) What are other users’ experiences with the COPR version of KiCAD?
(One version back is sometimes a safe choice if your are interested in stability. I would like to know whether users’ experiences with the newer versions are generally trouble free)
B) How about, KiCAD be able to export files to previous versions of itself? (That is, where they do not require something that is not present in the old file format).
C) How about we allow bug reports to continue for one version and evaluate whether they are still relevant rather letting some AI simply dump them out of hand?
Hi @drm - I maintain both the Fedora KiCad builds and the Copr KiCad builds.
The Fedora builds have to go through the testing repository before being admitted into the production repository. So there will be a lag of 1 week between the time I make the build and the time it goes “live”. If more people tested the builds and left positive karma then the builds would go live sooner. We need three up-votes to bypass the 1 week delay.
By policy, we are unable to update KiCad major versions in stable Fedora releases. So when KiCad version 10 comes out, I can add it to Rawhide (as well as any Fedoras that are in beta) but I could not put KiCad 10 in Fedora 42 - F42 has to remain on the 9.x series.
That is where Copr comes in. We have three Coprs: nightly, testing, and stable. If someone on an older version of Fedora wants to upgrade to a newer version of KiCad, then they can install from the stable Copr. That Copr is built from the exact same source that goes into Rawhide, and I try to run those builds the same day that upstream does their releases. So the stable KiCad Copr should be entirely reliable and current.
Please be careful about the dashes in the release numbers. Those are most often a function of the distribution, not the upstream source.
For example, if someone updates wxwidgets on Fedora, they may have to increment the KiCad dash number and do a fresh build of KiCad to make it compatible with the new wxwidgets. Or Release Engineering will bump the dash number if they are doing a mass rebuild.
Occasionally, we may apply a patch to KiCad and increment the dash number, but that is actually fairly rare. I’m not sure if Arch uses the same approach, but that is how Fedora does it.
If you want to have KiCad’s latest upstream patches, then you can use the Copr testing repo. But it will often change daily, so I wouldn’t recommend that for production work.
One way of working, when using KiCAD commercially, on several computers with many projects, is like you do - stay one release behind, to avoid having to deal with “bleeding edge” problems, and the potential inability do downgrade a KiCAD project, once it has been “touched” by a later version.
A number of ways to mitigate the risk to project (data) integrity:
Store each KiCAD project in a Git repository like GitHub, rather than on shared file systems.
Work is done on a local clone of the repository, changes are committed locally, and pushed back to the origin
Larger changes/experiments to a project can be made to a named branch of the Git repository, that can be shared between several users. The branch can be abandoned or merged back in to the main branch, maintaining full history of what has happened.
Changes are committed atomically to the local clone of the project repository.
Concurrent changes (by different users) to different files are merged without issues
Concurrent changes (by different users) to the same file are often handled merged automatically by Git, without generating a conflict, as KiCAD files are text-based
Before upgrading to a new KiCAD version, be sure to git commit any pending changes on local clones (you don’t have to push the changes back to the origin server)
This allows you to gracefully roll back any changes that a new KiCAD version makes to the project files, should it be required.
Once the project has been touched (opened) by a new KiCAD version, commit any changes that were made before making any work on the project files, to isolate the “project upgrade” into a single commit (with a commit message saying something like “Upgraded project to KiCAD 9.0.4”. This will make it a lot easier to downgrade the project and re-apply any changes made afterwards.
When making releases of a KiCAD project (generating gerber files for production), tag the release using the tag feature of git, associating a version number/name to the release.
This allows you to go back to an old release (tag) and make minor adjustments fixes, even if the project has moved on since the release.
The above way of working may seem a little convoluted, but the software development world has embraced Git as a source code repository, allowing tens or hundreds of people to work on the same set of source files while keeping a full history of all changes made (who did what, when).
This is (apparently) called "future compatibility, I.e, an (old) KiCad version reading files that have been made with a newer version. It’s also one of my wishes, because I believe this makes it easier for users to adapt newer versions earlier, and thus bugs will get found and fixed quicker. The problem here is the limited amount of hours that all developers have available together. They’re doing a great job and fixing around 300 issues for KiCad each month, but there are so many new issues opened that the total amount of open issues does not shrink. And this is going on for years (A few years ago it was around 150 issues per month, but also with around 1500 open issues)
Why do you think an AI is involved? I’ve dipped half a toe into the AI thing lately, and some results are impressive, but they’re not reliable and you can’t depend on it (for now).
I sort of see that, re git and github. My electrical design work is generally about small instrumentation circuits, you can see what I am doing here. The idea is open designs for professional grade instrumentation.
The designs are probably best done by one or two people thinking slowly and carefully. So far the collaboration is two instrumentation physicists, both former denizons of national labs and academia.
I started this as a way to affordably build a lab for myself during covid. But it seems to fill a need. We have users in africa, india, canada, europe and the USA.
