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.
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.
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.
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
Supporting professional users who need more assurance about schedules or need bugs fixed before the next public release is something that https://www.kipro-pcb.com/ 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
ā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.
Well spotted, another name to change.
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ā.
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.
ā¦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 far rather be happy than rightā, the wise man said.
Previously on forum.kicad.infoWhen 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.
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