There have been many bug fixes to the 5.1 branch since 5.1.5-3 was released, so a pre 5.1.6 build is interesting.
Nightly builds are available here
https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/testing/5.1/
Generally they are very stable, but sometimes a bug fix bites back
Build 543 4th February is looking good
This was a serious bug yesterday : https://gitlab.com/kicad/code/kicad/issues/3855.
My personal opinion is that the change which created this situation shouldn’t have been made at all, it was too intrusive for a bugfix release. But I respect easyw’s work. (EDIT: the bug wasn’t in the change itself, the change only made it visible in frequent situations.)
I don’t want to debate here, but just pointing out that my change improved a missing feature (eeschema highliting)
The issue that came out after the change was just an user Gui issue and not an issue on data format/loss…
moreover the problem has been promptly solved (1h from the open issue) … nightly builds (even semi-stable nightly) always have a little risk but in exchange for improvement IMO
Most important is for people who are prepared to report bugs found to use the 5.1 branch Nightly so that when Wayne decides to go for the next step release it has actually been tested
V6 is still too volatile for real work as the file formats are not locked yet
I commented in the closed request’s message thread that I’m not sure if it was good move to make, missing feature or not. It changes visible behavior in a way which may be confusing to new users and unpleasant to old users. There are pros and cons for it. I suggest users would take the next jenkings test build and try clicking a symbol to see how it works.
Here’s my message:
You’re not to blame in any way. The main culprit is the weird selection/action system of eeschema in 5.1. Mainly that items can’t be actually selected at all by clicking - and now it deceptively looks like they can. It has of course been radically changed in 5.99.
Its reversed out now, which I don’t like as the highlighting was a great improvement and did not confuse me
I used it while it lasted and I could have gotten used to it. Maybe I even kind of liked it already. Well, because it caused unexpected problems, there could have been more problems lurking. And then there were those conceptual problems.
It’s a pity that maui’s work couldn’t be used. I hope there comes a next time.
However, I see as a recurring problem with KiCad developement that the developers don’t seem to test their changes even in obvious ways. On the other hand I understand that, but is it too much to take a break before publishing the changes, thinking for a minute what could be affected and just play with it for a while? I often - well, sometimes - see bugs which should have been found with very basic trivial use cases.
It can be argued that that’s why the nightly builds exist, but trying out the nightly builds would be more tempting if we knew that it had a little bit of routine preliminary testing before publishing.
I don’t mean we all wouldn’t make mistakes, I would probably do the same (maybe will do if I ever get to KiCad coding) and in general the “develop quickly -> publish in nightly builds” system works, but sometimes those problems have been a bit too obvious. This is of course especially true for the stable branch.
Don’t get a wrong impression - I appreciate all that work very much, and I myself try to do my part when I test the builds. It has also to be remembered that there’s much going on in KiCad development and mistakes, sometimes basic, are inevitable.
BTW, here’s the changelog if someone wants to follow and maybe even try especially the changed bits:
The problem is that KiCad is a complex and broad piece of software, and has hundreds or thousands of “basic trivial use cases”. It’s not always easy for contributors or even lead developers to guess at which of those use cases need to be tested for any given change. This is the main reason we rely on many users outside the development team to find these kinds of issues through testing nightly builds.
We’re working on making KiCad more testable (in an automated fashion) where we can, but getting automated test coverage on a highly-graphical application (especially in a cross-platform way) is quite difficult.
IMO it would really convince advanced users to help test the software if there was an easy way to have two KiCad instances installed at the same time.
This way we could keep our “stable” for production work and “nightly” to test.
Shall anything go wrong with the nightly, one could report bug and wait for it to be fixed, using the stable in the mean time (if the bug is a “show-stopper”).
It’s not convenient to have to roll-back to a working version in a production enviroment…
There’s a change coming for that, but not for 5.1 testing builds. Stay tuned.
It’s already possible with some tweaking. (On Windows. This depends on on the installer and packaging on different platforms. On Ubuntu the packaging is already done for parallel installations.)
Thread bump.
Can anyone comment on the state of the current 5.1.6 nightlies? Or, for that matter, on what the developer’s plans for the 5.1.6 release are?
Thanks,
Walt
They have been very stable for me
The patching has slowed to a trickle, mainly Gerber plotting perfection work from JP Charras and permissions checking bugs by Wayne.
Wayne did post a couple of weeks ago about a freeze for translation soon.
They are clearly being very selective in the cherry picking, for example, some of the Master Coverity bug fixes apply to 5.1 source, but not applied yet
Since the 5.1.5 release contains few very annoying bugs, I’m on the Pre-5.1.6 for some time with my production files and so far no problems to me (except maybe locale-related “decimal comma” bug).
I am happy with these nightlies.
If you have interactivehtmlbom installed that may be the plugin’s fault. Update to latest from github.
We usually don’t cherry-pick the Coverity fixes unless they are critical or fix broken functionality.
We usually go by the critical bugs that are still open against the 5.1 branch - and right now there is at least one we need to investigate (which seems to be another macOS 10.15 issue).
Confirm, just installed the latest interactivehtmlbom plugin and seems the issue is solved. Thanks!
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.