Concerns for 3.0 builds
I generally download and test a 3.0 build every 2 weeks, but I decided to wait a little bit longer this time around considering the amount of bugs that I had experienced previously. My thinking was that if I wait longer, then it will be more stable next time with less bugs and crashes.
I have just come back from experiencing the latest build for 3.0 (which was f264716) and I can easily say that I had just experienced the absolute most difficulty that I've ever had with any build so far. I couldn't even perform basic tasks without the program crashing every 5 minutes. I think it's best if you just see for yourself by downloading the build and trying to compose a new score as you normally would. You'll come to notice that some of the most essential tasks cause crashes, such as placing brackets, editing ties, and even trying to add text to the Title frame. There's many, many more, but I simply can't list the amount of problems/crashes or causes due to the abundance and simplicity of the tasks.
This is, of course, very concerning for the future builds. I'm not a programmer myself, but I just can not understand how so many of these new crashes and problems suddenly appear over time rather than disappear. I think I'm gonna wait a little bit longer until I check out another build, you can find most of these problems by just testing the builds for about 10 minutes or so. Assuming that people test these builds all the time, I feel like any information regarding any particular crash can be gathered easily (such as how to cause it). I hope that these problems will all eventually be resolved.
Comments
3.0 nightly builds are highly experimental (and currently the code is very much in flux) and not meant to be used in daily use.
But if you find issues, do report them, one by one and in the issue tracker.
Thank you for sharing your concerns SirArsen. There is however nothing to worry about. MuseScore lead developer Werner Schweer is currently changing deep constructs in the software which will lead to more crashes. It's a typical phase in the development cycle of software, where the foundations are being refactored to make the software more performant and ready for new future developments. The immediate result of such refactoring is that more crashes will appear. But at one given moment this development will stop and then the focus will shift to making the software stable again. I'll check with werner and lasconic how we can improve our communication on which phase the MuseScore 3 development is in. So everyone can know what to expect and learn how to contribute.
In reply to Thank you for sharing your by Thomas
Hello, thank you for your swift response and providing insight on development. I can understand this development process and it is greatly appreciated that you provide this information. One thing I suggest is possibly adding a change log. If you just have a notepad with what was changed and what areas could be unstable, then I think it will help testers a lot when testing specific areas.
In reply to Hello, thank you for your by SirArsen
Well, the changelog is on GitHub, https://github.com/musescore/MuseScore/commits/master
In reply to Hello, thank you for your by SirArsen
As to which areas are being changed currently: all of them.
Kind of imagine building a house and always using wood to do it (MuseScore versions 2.x). For MuseScore 3 werner is switching the core building material (from wood to stone, as the analogy goes).