KiCAD 6.0.11 released

[johnboxall]

For more information see:
https://www.kicad.org/blog/2023/01/KiCad-6.0.11-Release/

[SiliconWizard]

Cool. Saw it appear on gitlab a couple days ago.
I wasn't expecting a new v6 release as close to the v7 release. Wondering if v6 is still going to be in maintenance when v7 is out?

[JeffYoung]

We weren't actually planning on a 6.0.11, but the Curl issue on Windows sort of forced our hand.

In general we stop doing dot-releases once the next major version comes out.  So I wouldn't expect a 6.0.12....

[hpw]

For more information see:
https://www.kicad.org/blog/2023/01/KiCad-6.0.11-Release/

Well, stable release(s) as always 

The other question rises, as V7 will be released at the end of Jan 2023 ... so go with soon with new or deal with old stuff?

[golden_labels]

JeffYoung: does it mean that from now KiCad will use whole numbers for each release?

hpw: what is the reason for laughing? “Stable” doesn’t mean “without bugs”. It just  it is meant for general public — in contrast to nightly, rc, main branch’s tip or future releases.

[Doctorandus_P]

JeffYoung: does it mean that from now KiCad will use whole numbers for each release?

Mayor version updates are now sort of expected once a year, while increments in the third number are for bug fix releases, and I expect these to continue with a rate of about once a month. The second number is unlikely to be used again. It was used for somewhat mayor updates that could introduce some incompatibility because of new features and it was used for V5.1. But the transition from V5 to V6 took three years.

In general updates in the third number should always be safe to install, and are recommended, while mayor version number updates are likely to cause compatibility issues, and once a project has been saved in the new format, it can not be used with older versions of KiCad anymore.

[SiliconWizard]

As with any new major version, I suppose that for people working collaboratively, they better stay with v6 until all their partners have upgraded to v7.
So I guess don't rush it, unless you're a lone engineer.

[hpw]

hpw: what is the reason for laughing? “Stable” doesn’t mean “without bugs”. It just  it is meant for general public — in contrast to nightly, rc, main branch’s tip or future releases.

Look, as an old SW engineer...

The count of (remaining) bugs is a constant. As the complexity of  a product, the amount is getting any larger.
The question is how or when they get fixed. 

as on Keysight AWG no any more updates for an xxxx$ product, nightmare with Siglent SDG/SDM... all SW related 

[Doctorandus_P]

The count of (remaining) bugs is a constant. As the complexity of  a product, the amount is getting any larger.
The question is how or when they get fixed. 

The KiCad developers are doing a quite impressive job collectively, and bugs get squashed quite agressively. I've reported bugs myself on gitlab, and some were fixed with "patch commited" in less than half an hour after reporting it. This of course only happens with small things that are easy to fix, but things getting fixed within a few days is quite common.

If you look at the release notes:
https://www.kicad.org/blog/categories/Release-Notes/

Then several of the (nearly monthly) point releases have more then 100 bug fixes in them. So that is over 3 bugs per day on average.

Maybe some of the skepticism originated from the schematic file format change. The schematic file format was completely overhauled (into an S-expression based format) in the transition from V5 to V6, and big changes such as that are likely to introduce or uncover lots of new bugs and those take time to fix again.

[Uky]

I have filed a l o t of bug reports with the support departments of several high-end CAD/CAE tools
over the years. But as the products matures and the number of bugs subsides, the new major release is 'round the corner
and the process starts all over again...

 

[JeffYoung]

> does it mean that from now KiCad will use whole numbers for each release?

Pretty much.  Now that we're on a (nominally) yearly schedule there isn't really any time for 7.1, etc.

It made more sense earlier when we were both on a longer release schedule and had a whole bunch of GUI rewriting to do (which could be done without file format versioning issues).

[hpw]

The count of (remaining) bugs is a constant. As the complexity of  a product, the amount is getting any larger.
The question is how or when they get fixed. 

The KiCad developers are doing a quite impressive job collectively, and bugs get squashed quite agressively. I've reported bugs myself on gitlab, and some were fixed with "patch commited" in less than half an hour after reporting it. This of course only happens with small things that are easy to fix, but things getting fixed within a few days is quite common.

If you look at the release notes:
https://www.kicad.org/blog/categories/Release-Notes/

Then several of the (nearly monthly) point releases have more then 100 bug fixes in them. So that is over 3 bugs per day on average.

Maybe some of the skepticism originated from the schematic file format change. The schematic file format was completely overhauled (into an S-expression based format) in the transition from V5 to V6, and big changes such as that are likely to introduce or uncover lots of new bugs and those take time to fix again.

Good, that they run as Scrum related management. Just look on the burn down chart what shows opened related to fixed.

Sometimes there is a workaround or nice to have but hard once is a pitta as it comes to mal functions or crashes.

It is always best that the test team is separated from the developer team.

This was once the case on MS (old days) and now any more, so we have the mess as testing by SW server. While the test team tells OK/NOK. In addition automatic GUI testing is an additional mayor task, while human being test it sometimes/often any complete different.

As once tells, SW as Banana ware tested by the end-user 

[SiliconWizard]

> does it mean that from now KiCad will use whole numbers for each release?

Pretty much.  Now that we're on a (nominally) yearly schedule there isn't really any time for 7.1, etc.

It made more sense earlier when we were both on a longer release schedule and had a whole bunch of GUI rewriting to do (which could be done without file format versioning issues).

Well, the traditional version numbering is usually something like: major = potentially breaks compatibility, minor = new features that don't break compatibility and that are still "in line" with the major version, and the third digit - sometimes called patch - is for bug fixes.

So if you're never gonna change the minor digit between major releases, shall we assume that KiCad will now only get bug fixes between major versions, but never new features?

[JeffYoung]

> So if you're never gonna change the minor digit between major releases, shall we assume that KiCad will now only get bug fixes between major versions, but never new features?

Pretty much, though we've been known to push the blurry line between bugs and features.... 

[SiliconWizard]

Oh and, speaking of v6 -> v7, I usually update libraries from git, and the latest commits in the main branch are now for v7, which can't be open with v6. But I'm still on v6.
I used a 'git checkout 6.0.11' command to revert to 6.0.11. Hoping that's what works. Seems to so far.