Yet another release date 6.x question

I have been using Kicad for my hobby project for a while.
Starting up a new project at work I have tried introduce kicad to my organisation. Members preferring other tools directly pointed out lack of release date for 6.x and in general long unplanned release cycles.

I have no opinion about this but would like to provide my organisation with latest information about releases and dates.

I don’t understand their problem.
I would understand it if they said: “We can’t work with the features available in 5.1.9 so we need 6.x, but we don’t know the release date.”
The stable release (5.1.9) is for real work. The nightlies are for enthusiasts.

1 Like

KiCad simply does not set release dates, they release when the code is ready to be released.

ISTR my previous study of KiCad releases gave a typical figure of 9 months from feature freeze to final release. I think feature freeze for v6 happened a month or so ago. My WAG : 95% chance that v6 will be released sometime next year.

Planned release cycles mean one of three things:

  1. Baby steps of exaggerated importance
  2. New features get delayed in the background to give certain feature next time
  3. Buggy releases

Either a tool meets your needs or it doesn’t. If they have specific unmet needs a ‘donation’, that could be less than the current license, might get that need met ‘to order’.

I will not argue with your arguments, they all have their own values.

Your responses tells me that there is no release plans, finished when fineshed.

My personal comment is that a open source project not handled in a professional manner will never be a favorite by companies. I will have a hard time avoid fusion 360.

At least one of the worlds largest tech firms bricked you phone on schedule? :wink:

1 Like

Releasing when ready and being honest to users is professional.
Pushing out broken code to meet a schedule is marketing, not professional.

KiCad has commercial support options for companies that want that route


If you find KiCad lacking, there are only 3 options:

  1. help develop KiCad
  2. give money to fund others to develop for KiCad
  3. use something else

Option 4) “KiCad magically gets a full time development staff” is not an option.


I think the open-source vs. commercial thing is kind of orthogonal to release schedules.

I know of many commercial software packages that have no fixed “annual release cadence” and go years between updates. Then there are others that have set a cadence of releasing once per year. My experience with the latter is that the annual releases tend to not be very exciting (or else exciting in the wrong way, since they didn’t have enough time to fix bugs).

In general we would like to move KiCad to a slightly faster release pace than we’ve had in the past. This is not the same as being strict about a release schedule: I don’t think we would ever make a release if we knew about critical bugs (that are in our power to fix) that were unresolved by the scheduled date.

The development of 6.0 has involved a large amount of fundamental architecture improvements that were necessary to make various desired features possible. This fundamental work will pay off beyond 6.0, so it should be possible to release a 7.0 with a good set of new features in less time that it is taking to finish 6.0. That’s the plan, at least :slight_smile:

Supporting professional users who need more assurance about schedules or need bugs fixed before the next public release is something that provides, by the way. They are essentially full-time development staff for KiCad already.


This idea that scheduled releases are a benefit to the end user has no basis in fact. It could be true or not. My experience is that it has no benefit. For paid software, bugs should be fixed as soon as possible. New features should be released when they are stable and not before, unless you agree to be a beta tester.

My company uses Altium, which has annual releases. It is not a benefit to us, but rather the opposite. Some considerations:

  • There have been several major interface changes that move important items to different, but not easy to find, places. Relearning is costly.
  • There are new bugs introduced every year.
  • Altium uses the schedule to try to goad users into updating or paying annual maintenance. A small, but non-zero number of bugs provides incentive to pay for support, and may be good for this income stream.

To Altium’s credit, I can open > 10 year old designs and work on them with the latest version.

I, too, am impatient for V6, since it has features that make it viable for my job. But, I don’t contribute, so I can do nothing but wait. That being said, my company has paid for features on open source software in the past, but it was software we were already using and had proven value to us. If V6 proves to meet our current needs, we are more likely to pay for enhancements, and if we can ditch a few Altium licenses, that frees up a lot of cash.



Bobc is notoriously pessimistic in his predictions and has been right more often than notoriously optimistic other members of this forum :slight_smile:

“The first release candidate hopefully some time early next year” (meaning 2021) has been repeated many times, probably because the project leader has said it.

Unfortunately the time between rc1 and the final has been too long in the past. IMO the project should change the naming to what it actually is: nightly builds are alpha, rc1 is actually what other projects call beta1, i.e. new bugs are actually still expected. Release Candidate means usually “ready to be released as is unless new serious bugs are found”, only serious bugs lead to a new RC, and no known bugs have been postponed after RC1, not even a single one. That would make the expectations more realistic and the end of the waiting cycle more predictable in short term.

But that’s a smallish detail. My observations from the past tell that the most difficult problem for the project is lack of good testing. Every KiCad user could help with that. If KiCad would have got more testing before and after rc1 and more of the bugs would have been found earlier than later, the release schedule would have been tighter. As it is now, it has happened that a new bug is found, then a new one, then a new one… and suddenly we notice that 6 months has gone. Even though the version naming with KiCad Release Candidates have been way too optimistic, it would have been more realistic if testing would have covered more and revealed more of the bugs before the RC1.

Everyone can help to shorten the release cycle in this phase (after the feature freeze), and it will actually work. So everyone, please test, test, test, and report bugs. It will make the release cycle shorter and more predictable.


I’m not sure if the 5.99 is in the “feature freeze” stage right now (as it typically means, all the planned features are implemented), it’s rather “specification freeze” (i.e. “we’re not adding any new features for the release”).
But indeed, the more testing in early phase, the better quality of the release.
IMO when the “file formats freeze” will be announced, more projects will be moved to 5.99 and it will result in better testing.

1 Like

Well spotted, another name to change. :slight_smile:
Indeed the real feature freeze and especially file format freeze are practically important, although it has been stated that the file formats won’t be completely frozen because there’s always possibility for bugfixes. Maybe it would be “file format feature freeze”.

1 Like

There is only one non-bugfix file format change planned that isn’t in yet (arcs in polygons). As this only impacts the PCB, you can consider the schematic and symbol formats “done” for V6.

As you mentioned, we could still make changes to the file formats to fix bugs, but there aren’t any open bugs requiring format changes that I’m aware of at the moment.


When that happens, I will start using 5.99. File format stability is so important and in my opinion marks the start of Beta phase

…and the bugs are found earlier only if people test the features. The only file format bugfix after the feature freeze which I’m aware of was the result of a forum discussion and/or a bug report: Discussion about filled polygon implementation details.

It’s intriguing to see how one new feature (rectangle) combined with a less used old feature (create circular pattern with rotation) led to an impossible situation and the file format had to be changed, leading also to better, more consistent behavior and UI and a new feature. What was the chance of this being noticed before the final release?

I would like to.

Where can I download the nightly builds for openSUSE Leap 15.2?

“I would far rather be happy than right”, the wise man said. :slight_smile:

Previously on When will Kicad 5 be available? where we had pretty much the same discussion with the same posters!, I predicted 5.0.0 final to be 2018-08, it was actually released about a month earlier in 2018-07.

Here is the 2021 version.

Btw, Happy New Year everyone! Let’s hope 2021 turns out better.


The V5 6 month lag from RC1 shows that RC1 was a Beta, not a Release Candidate
I wish that we only used RC for builds that are tentatively fit for launch, it is misleading to users.
I will still happily test a beta, but my expectations are very different

1 Like