Personally, it doesn’t bother me much that the developers did not have time to fix it in 7.0.7 and moved it to 7.0.8, the question is that this cannot be fixed conditionally in 7.0.11 and the project will close… this will happen in a few months… compatibility between 7 and 8 is minimal as between 6 and 7… the new format has a lot of errors, etc… as a result, you are forced to live with old errors or new ones with the new version… I remember my transition from 6 to 7 and only a month ago I managed completely transfer your projects before there were a lot of mistakes…
in my understanding, stability and backward compatibility are important for a cad system… this is not a browser where constant security updates are needed…
Some bugs may not be fixed soon because they are actually caused by third party software like OpenCascade, wx Framework etc and depend on their bug fix cycles.
Others are not reproducible
Others depend on KiCad needing structural changes to match. This is happening with 7.99 supporting flat hierarchy schematics to match Altium. Remember that in a version cycle,like 7.0.x, no new features are allowed. Importers frequently fall into this category.
Others are just queued for developer time.
1 Like
you also need to take into account that the developers themselves do not test anything; as soon as you see that your error has been fixed, this does not mean that it is fixed (there is no verification) this happened several times to me personally… I don’t know exactly how it works and why there are no testers at the implementation stage changes, but that’s true… I’m not talking about a deep code check, but a banal open and save… and all this ends up in a stable branch…
Everybody is free to grab a closed bug report issue and test it…
2 Likes
I am not sure that before the 7th branch is closed, the board importer will be completely fixed… although this is not a new function… about importing circuits, it is clear that they were not originally in version 7… in principle, I expect an answer that error correction is now paid for as this was from 6.11
No, it will never be “completely fixed”. No single KiCad release will ever have zero non-critical bugs in it. That’s not a reasonable expectation. No version of any software has zero bugs. At least not when talking about software that’s the size of KiCad.
When no more development is done on v7, there will most definitely still be open bugs that’s applicable for v7. There’s simply no way to change this without completely stopping development of new features for a foreseeable future. No one would be happy with this approach, because everybody wants new features, as well as bug fixes.
There are currently ~1900 open issues i KiCad, and ~16000 closed issues. The issues that will be fixed first are:
- Critical issues
- Issues with lots of up votes
- Issues that doesn’t have a workaround
- Issues that someone with programming skills feels strongly for and wants to put in the time to fix.
- Issues that someone pays for to be fixed.
At least that’s my understanding. I’m not a developer, but I’ve reported lots of bugs that have been fixed, often very quickly.
3 Likes
They test what they can. Often they cannot because they don’t have the right OS or right third party ECAD like a particular Altium version
No critical bug has been transferred, but 15570 is critical and marked milestone 7.0.8 and is not yet fixed as of the time of writing this.
Perhaps there is something in the works that will get into 7.0.8 in a RC2 before the release of 7.0.8?
#15570 - I’m not sure this one is correctly classified as critical (@Qbort may disagree) – I would call it “high” instead. The backstory behind this bug is that it was accidentally made possible to open some non-KiCad designs when running KiCad normally (with the project manager). It was only supposed to be possible to do this standalone (launching the schematic editor or PCB editor without opening the KiCad project manager). Because of this, the code is not ready to handle the case of a user opening a non-KiCad design with another design already open in this situation.
#13285 - this is a low priority issue, as it only affects ERC.
#15585 - this is an importer issue, which was noticed late in the 7.0.8 development cycle. We generally classify all importer issues lower, because no import will be perfect and users should expect to have to double-check all imported designs.
#15584, #15583 - same as above.
#15485 - as this issue involves the third-party STEP handling code, it may be more complex to identify or fix. However, it doesn’t seem to affect that many users. It will likely not get fixed quickly unless it turns out to affect a lot of users, or a developer gets inspired to work on it “for fun”.
So that everyone is clear: setting a milestone does not mean “we definitely plan to fix this issue in this version”. Instead it is a “TODO” list of issues to consider fixing. We add and remove milestones from issues regularly, depending on their severity, how many users they affect, the difficulty of fixing them, etc.
Bugs (not new features) are set to a future major release milestone (e.g. 8.0 intead of 7.0.9) when they don’t affect the 7.x branch, or when fixing them on the 7.x branch is not feasible for technical reasons. But, they may have the milestone changed or removed during the 8.0 development process. This is normal. Please do not view the milestone lists as a promise of what will be in a future release: we use them on the team to track what has happened and what people might work on in the near term, not as a guarantee of anything.
Developers test using whatever test information is provided in a bug report. If that test information (example project, reproduction steps, etc) is missing or does not cover everything, it is quite easy to miss a further problem. This is why we rely on users to perform additional testing.
There are testers: you. The KiCad project operates with its user base as testers, relying on users to install nightly or testing builds after a bug has been fixed and confirm that it has been fixed for all their use cases (which the developers do not have access to).
8 Likes
As has been explained before, board importers are never going to be 100% accurate. The board importer is not “broken”, it is simply incomplete. Any importer will likely never be 100% complete, but will get more complete and more accurate over time. We explicitly do not have a goal of saying “in KiCad 8, the importer is 100% done, has no issues, and imports all data”. We will never say that, because it will never be guaranteed.
7 Likes
100 percent and not possible by definition… there is a list of parameters that need to be transmitted exactly… for example, such as size, shape, layers, etc. This is how most importers work… but for the CAD system this is generally a necessity…
Now 15570 got fixed in 7.99 nightly. It is tagged “needs cherry-pick” and it is thus possible or even likely that the fix will be backported to 7.0.9.
2 Likes
And now 15570 has been cherry-picked (“backported”) to 7.0.x too, see:
It didn’t make it in time for 7.0.8 but will be available in 7.0.9 and can be found in the testing builds (of 7.0.x development, NOT the same as nightly 7.99!) already.
2 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.