Could we have a version 4.1 release?

The current git version of Kicad has some new features that would really benefit. But I have found that the git version crashes all the time, so it’s not very usable.

Could we please release a stable/testing version of Kicad really soon? Unless if version 5.0 is less than 2.5 months away, I feel like it would be worth it. Just include the new features that are already there (like reverse rotate), and get rid of any significant bugs.

So could we please have a 4.1 version so that we can use the new features until 5.0 comes out?

1 Like

Bugs and wishes:

1 Like

That is a lot easier said than done. Bugs are the #1 problem in software, and no one has yet found a foolproof way to avoid them. Finding and fixing bugs is the most time consuming part of software development. We have a saying “there is no silver bullet”.

A “bug free” version of KiCad with new features would be called 5.0, rather than 4.1, but that is just a matter of naming. If you want to bring forward the release of 5.0 to “really soon”, you’ll have to invent some new software development techniques.

I was expecting v5 to be frozen by now, but for whatever reason that has not happened yet, therefore I expect v5.0 to appear sometime in Q4 2017.

The only way to help the devs is to “eat the dog food” - run the nightly builds, find bugs, make detailed bug reports.


I think there is a mathematical proof by Alan Turing that shows that in general software can not be proven to be correct. In special cases yes but currently it is a lot of work to do it. This is done for critical parts of software. (To proof software correct you need to limit what it can do.)

Also i think there is not enough testing done in many open source projects. It seems people don’t like testing as much as creating new features.
Maybe this is because finding problems does not get the same amount of glory as implementing a really cool feature. Yes people complain about bugs but most people complain about missing features. (As long as the software is usable even with the bugs that are noticeable by the normal user. Don’t forget most bugs are never encountered during normal use.)

sometimes you can’t even imagine under what circumstances bugs appear… only after they appeared you ‘get it’ - sometimes. This is especially frustrating as the development process usually involves a lot of thinking, tinkering and testing of seemingly logical constructs and chains… bugs by their very nature are the opposite of this, it’s very hard to ‘predict’ them.

I specialize in secure and safe systems at university. The only thing i can say is that there are tools out there that could help a lot. But they are not used in many open source projects. (Most static code analyzers allow the use for open source projects for free.)

In c and c++ a lot of bugs are “predictable” because they stem from the idea that the developer is responsible for managing all details of the memory. Not predictable in the sense of we have a mathematical model that predicts them but because every software written in these languages has this sort of bugs in them.
Stuff like buffer overflows, integer and floating point over/underflows especially when casting between different datatypes. (There are a lot of implicit casts done by the compiler. Most developers are not aware of them!)
And yes i am not necessarily talking about bugs the user will ever encounter. I’m talking about security critical bugs a hacker might want to exploit. (The later sometimes cause problems for users. I think we had one user that managed to get an integer overflow in the gerber export a few month ago. I don’t think this has been fixed by today.)

I definitely bow to the master… way over my head. I’m happy if I can get & keep my python scripts running :grin:

I sincerly hope, that one day I’ll master unit tests in python and am able to effectively use them to maintain my code. But so far, nothing like that happened… :disappointed_relieved:

Hmm… are you suggesting that there are static code analysis tools that allow use by open source projects, but that we’re not using any? :upside_down:

Re: the actual topic: probably not. The plan has been to head straight for 5.0 since 4.0 was released, and since we’ve been following a roadmap for 5.0 it would be very hard to cut a 4.1 release. Things are just not ready for any release at all - there are many tasks on the roadmap that should be completed before any release is made, but that are waiting for other ones to be finished first because that makes the most sense for a major release. Since the latter tasks are already underway, it wouldn’t really be possible to finish up the former in a hurry to get a 4.1 out.

1 Like

It is unfortunate but I think hardening a project like KiCad against such exploits would be a truly monumental undertaking. It’s easy to “accuse” developers of being more interested in implementing features than fixing bugs, but that’s unfair - a balance has to be struck. If we were to spend all our time laboring away at making KiCad secure, to an outside observer it would look like the project had totally stagnated and people would very quickly give up on it. As we hemorrhage users we would quickly lose developers too, and soon the project would be dead. Something has to be done to keep users happy, because that’s whom it’s for.

It is also unfortunate that in a project this large and byzantine, there are so many bugs that they absolutely must be prioritized, and this occasionally makes some take a long time to fix. I would hesitate to interpret that as disinterest in fixing bugs. Also, one should note that sometimes bugs are found in sections that are slated for replacement, in which case it is often a better use of time to move forward with the replacement and let the bugs remain in the meantime.

1 Like

Fortunately KiCad has limited opportunities for hackers. Not much need for high privilege system access (the GitHub access is an exception), small installed base…
The worst case is probably ransomware getting into the downloads

I hope people using it to process Other People’s Files (OSH Park at least) have it sandboxed well.


An infected footprint or 3D model would be a more likely threat

That’s why it’s important that you both work with users in mind, and also refuse to just blindly implement whatever the individual users demand :wink:

1 Like

I most clarify what I meant by “any significant bugs”. I’m just talking about the bugs that constantly get in the way of the program’s usability, such as crashes. I have found that with every git version of Kicad I’ve compiled, it’s not long before it runs into a segfault that crashes the program.

Also, it makes no sense to have a decimal in the version number if you never do point releases. Also, it’s not good to have this much time between releases. You got to have point releases.
I have no intention to change any of the plans for version 5.0, and I don’t insist on rushing it. I am definately talking about a version 4.1 release here; not trying to change anything about the 5.0 release.
Just take some already-working features in the git (especially the simpler ones like reverse rotate), merge them into the 4.0 codebase, and make sure it isn’t crashing all the time. It probably doesn’t even need to have as much testing as the '.0 releases. Maybe it won’t even be a true stable release, but a “testing release”. (If it were Manjaro, it would be available the “Testing” repositories). I’m just trying to suggest something that won’t have too much impact on this programs development.

Sure; those tasks should be completed before the next major release. But I still recommend putting out a minor release much sooner. There’s just some small but useful features (like reverse rotate) already there that we might as well be allowed to use until the next major update comes.

I would recommend forgetting about security for a 4.1 release. It’s just not worth the effort of the developers for a small release like this. People who really want security could just remain with 4.0 and wait until 5.0 to upgrade. They would have to do that anyway, under the current release plan.

Ok, well the person you need to convince is not me, but Wayne Stambaugh :slight_smile: He seems like quite a sensible guy and is realistic about what can be achieved with the resources available, and generally errs on the side of caution when releasing stuff.

I will predict what he will say: “are you volunteering to do it?” :slight_smile:

I don’t see how the 3D models can do anything other than not load. Neither the VRML nor IGES/STEP models can even be used to cause something as simple as a buffer overrun.

1 Like

I’d like to see you try :slight_smile:

The problem is, that some of those features change the data files and you get version conflicts if you load them in another version of KiCAD.
We run into this all the time.

If you want new features with bugs, use the nightlies.

If you want to get stuff done, use the stables.

If you want a higher cadence of the stables, the development team needs to grow in size as you need more hands on deck.


And there is also the option to donate cash to the project via the CERN donate page.

1 Like