[Mod edit by hermit & gkeeth: This post and its replies were originally part of another thread. The developers think this post is misleading and is more about the posters frustration that some bugs important to them aren’t fixed in this release. See replies to this post for clarification on the bug squashing process.]
all critical errors were transferred to version 7.0.9 based on the gitlab branch… the point of this update is only for updating… there are still many errors with the sizes with the importer and with graphics… error correction is also lame, for example I had to open one twice the problem because after fixing it it remained the developer did not check his work… thoughts out loud…
Even though the emotional expressions vary between people, it conveys the idea / observation that some bugs that are important to some users have not yet been fixed.
We do not delay bugfix releases until all bugs are fixed. We release bugfix releases at a regular cadence (trying for approximately once a month) and any bugs that have not been fixed at that point are transferred to the next milestone (7.0.9 in this case).
For each release, there is a bug fix list on the blog part of the KiCad website. I think it is useful to post a preliminary list for these release candidates. It helps people who want to help with testing to focus on the things that should have been fixed, and to ignore the buts that have not been fixed yet.
Those lists are already being made for the release notes, so posting the preliminary list here should be a very low cost effort.
On the other hand, three high priority bugs were transferred. Two of which we require modifications to the upstream packages. The third has limited reproducibility (crash every 1-2 hours on one machine but not another).
This point release does not fix all bugs, but enough that by getting 7.0.8 release, many KiCad users will have a better experience. The RC is being announced to get as many users as possible check that no nasty regression has happened.
a similar situation occurred with version 6. Some bugs were moved to version 7. As a result, branch 6 was closed and the transition was impossible without converting the projects… All the errors remained and during the transition we received many non-working plugins and many new errors… Now this is repeated with version 7… Some of the errors were transferred to another 7.0.8 part in version 8… visually all this looks like an update for an update… there is a certain schedule and you need to meet it without corrections… I could be wrong but everything looks exactly like this…
No, there is a point where a critical mass of bug fixes, improvements, and feature additions have been made, and those changes need to be released within a reasonable timeframe so that users can actually get those improvements. It’s pointless to write code to fix bugs and add features if you’re never going to ship the improvements.
You seem to think software releases should be delayed until all bugs are fixed - this would result in no software ever being released.
I just don’t want to get a repeat of the situation with version 6… When the errors remained and the branch was closed and the transition to 7 was impossible due to a large list of errors… These errors did not allow the projects to be transferred correctly… As a result, the transition was completed approximately six months after the release of 7…
Sorry, but most of the bugs went into version 8 instead of being transferred to the 7.0.9 branch… These bugs are not new features or anything similar that affect the transfer to the 8 branch
The concept of a critical error is relative… It is enough to change the priority, transfer it to another branch and show a beautiful screenshot… That there are no errors… For reference, some errors are more than a year old…
7.0.8 is the eighth release of bug fixes for the 7.0.0 release last February.
7.0.8 has absolutely nothing to do with 8.0.0
7.0.9 will probably occur in a few weeks when a sufficient number of still existing bugs are solved.
There may even be a 7.0.10 some time after 7.0.9
8.0.0 does not exist.
7.99 will become 8.0.0 NEXT YEAR.
7.99 is available for those who wish to contribute their time and effort into making sure any new (and old) features that will be introduced in 8.0.0, have as few bugs as possible upon the release of 8.0.0 next year.
Please try to understand the project release numbering and purpose.
I don’t really understand what it means that version 8 doesn’t exist… Here it exists 8.0 · KiCad · GitLab
I understand that this is 7.99 which will eventually become 8
Version 7 and version 8 have a connection in the form of transferring errors like versions 6 and 7 at one time… I repeat, some errors are more than a year old and some are 2 years old
That is a guideline showing what has been completed and what is still to be completed before 8.0.0 is a suitable product for release.
Please read the post by @Seth_h again. Some bugs are easy to fix, some hard, and some are unable to be fixed until other problems/features are changed.
I think it would help if you listed the bugs that you are currently waiting for to be fixed. Then we can see how many votes these have, and get a better understandning of why these particular bugs hasn’t been prioritized yet.
Give us a short list with the bug numbers, not just vague descriptions. If I agree that these seem important, I’ll give them an upvote so that the chances of them being fixed increases.
#15570 #13285 #15585 #15584 #15583 #15485
I want to note that some of the errors are transferred from version to version as a result everything goes along the path of 6.11 when it was abandoned with known errors and version 7 was as crooked as possible… And probably this would be normal, but there is no backward compatibility… Just as there is no full compatibility of the transition from version 6 to 7 without breaking the project or a lot of manual work
I can understand that it’s frustrating when bugs have a set milestone, but doesn’t get fixed in the version that it was planned to. But the reality is that no one has unlimited time, and things often takes more time that initially estimated. It’s better to release a bug fix release with 79 bug fixes, than to wait another 6 months and release it with 200 bug fixes.
Most of these bugs have 0 upvotes, so it doesn’t seem like there’s a lot of people waiting for these to get fixed.
I’m not sure exactly how this works. It looks like 15570 is a critical bug with milestone 7.0.8, but it’s not transferred to 7.0.9?
