Electronics > KiCad

KiCAD 6.0.11 released

<< < (3/3)

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:

--- Quote from: Doctorandus_P on January 29, 2023, 12:04:43 pm ---
--- Quote from: hpw on January 29, 2023, 11:46:56 am ---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.  :clap:
--- End quote ---

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.

--- End quote ---

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  :-DD

SiliconWizard:

--- Quote from: JeffYoung on January 29, 2023, 04:25:03 pm ---> 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).

--- End quote ---

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....  8)

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.

Navigation

[0] Message Index

[*] Previous page