MuseScore 3.3 Release Timeline

• Ağu 27, 2019 - 08:56

We are nearing the release of MuseScore 3.3!

Thanks to the hard work of the community, we improved already stable release of MuseScore 3.2.3.

  • @DLLarson exposed a lot of properties and made fixes for the Plugin API
  • @Tantacrul redesigned and @dmitrio95 implemented the redesign of the palettes widget. The goal was to simplify customization of the palettes and get away from the master palette. Check it out in the Beta version and let us know whether we succeeded :)
  • @MarcSabatella made a lot of improvements for the accessibility of the editor including navigation
  • @lvinken made a lot of improvements for MusicXML export and import
  • @Jojo-Schmitz made MuseScore work with the latest version of Qt on Windows which reenabled NVDA support

Many other developers and testers reported and fixed bugs and implemented improvements which have made MuseScore better and more stable.

Timeline

August, 29-30

We are going to prepare a Beta version of MuseScore 3.3 on August 30. Should you know about any fixes/improvements that should go to the release, please let us know so we can prioritize the pull requests merging process. Up to date information about the pull requests that are going to be reviewed and might be merged is available in the related GitHub issue. No new features will be included in the release after this date.

September, 1-18

Beta release testing period. Only fixes and small improvements will be included in the release.

UPD: October, 1-2

Previous date: September, 19-20
We are going to prepare the Release Candidate on September 20. Should you know about any regressions in MuseScore 3.3 Beta compared to MuseScore 3.2.3, please let us know so we can quickly prepare a patch.

There will be no new strings for translation after this date.

UPD: We want to include the changes to the Save Online workflow to synchronise the editor flow with the new musescore.com upload interface. This task moves the dates a bit.

October, 3-15

Previous date: September, 20-25
It's time to test the Release Candidate thoroughly and report any regressions found. We plan to address the regressions asap. New Pull requests, except for ones fixing regressions, won't be merged.

October, 18-22

We decided to prepare an update for the release candidate since the known issues related to the updated Save Online workflow prevent making final release in time.

See MuseScore 3.3 Release Candidate 2 announcement.

October, 22-24

Release date. All translations will be grabbed as they are around 9:00 (UTC).

All dates are realistic estimations which might be changed at any time. There are no guarantees :)


Comments

What is the status/plan for the new Qt on other platforms? Plugins cannot take advantage of the many ECMAScript 6 improvements until they get the new Qt, too.

In reply to by BSG

Qt > 5.9 for macOS would mean to drop support for macOS 10.10 and 10.11 (or have a separate build for those), so is unlikely to happen any time soon.
For Qt 5.12 we're still waiting on 5.12.5 to get released (and also to be made available on AppVeyor, for the Windows builds), so for the time being we got to stay on 5.12.3, 5.12.4 having a bad bug, esp. with plugins, see https://bugreports.qt.io/browse/QTBUG-76509

In reply to by Jojo-Schmitz

Having two different Javascript languages will just about guarantee that plugin writers will make plugins that fail in 5.9. ECMA6 has some very attractive features, such as destructuring assignment and "for x of y" element iteration. This is laying a mine-field.

In reply to by Jojo-Schmitz

That doesn't address the problem. That's just putting up a sign, *No se habla español". That way, plugin writers can make the plugin say "Sorreee!" , a world of no-Mac plugins. Plugin writers would have to be acutely aware of ECMA 5/6 differences, with no way of checking that they got it right,

In reply to by Jojo-Schmitz

Sorreee, to me printing "Sorreee!" is "failing". A better solution is needed. "The Black Art of Plugins Manual" would have to explain very carefully, "Ye must write plug-ins in an olde dialect of ye Java-scrippt, lest it not work on ye olde Mac!" What about the C++ code? How can you make fixes and upgrades or take advantage of Qt improvements if Mac not?

In reply to by Jojo-Schmitz

I'm willing not to code for new ECMA features, sweet as they are, as long as my plugins can be debugged and be ensured that they will work without change on all platforms. The problem would be people on windows, esp Javascript programmers used to ECMA6 features, writing programs that either fail on the Mac, or are declared Mac-only (with version check) for this reason alone. As a matter of fact, if the Mac is forever stuck with 5.9, plugin writers like myself writing on the Mac can't possibly create plugins with this problem. But not so plugin-writers in Windows. Someone will have re-debug them in ECMA 5.

In reply to by Jojo-Schmitz

As I just explained, I have no choice. 5.12 will never be on the Mac. Easy enough dinner menu choice with only one item on it. But this threatens to destroy the future plugin library. Anyone on Windows knowingly or unknowingly using an ECMA6 feature renders the plugin inoperable on the Mac for all time.

In reply to by BSG

Not true. We may be able to build 2 MuseScore versions for macOS, one with Qt 5.9 and another with 5.12. Or just switch to 5.12 and drop support for macOS 10.10 and 10.11 (with MuseScore 3.2.x remaining the only version for that), maybe @Anatoly-os can share some statistics about the platforms used?

What features exactly are you talking about BTW? And why hasn't that come up before, we're using those different Qt versions since quiote a while.

In reply to by Jojo-Schmitz

The first time Dale sent me a plugin he had built, it didn't work, it "had syntax errors" and it took me a while to figure out that this was the problem. He reverted to 5.9 for me. Here is a beautiful page listing and explaining all the ECMA 6 features. http://es6-features.org/#Constants . The features are many and beautiful. It's been around for a while, and serious Javascript programmers are used to it. 2 versions might be a way to go (but MacOS 10/11 users couldn't use such new plugins). I myself have built MacMuseScores with 5.12, and had to revert to 5.9 to ensure that my plugins (which will be very popular when 3.3 is born for real) would continue to work.

In reply to by BSG

As far as I can see for most of those new ECMA 6 features there are ways to write it in ECMA 5, so a workaround is available. Or are there ESMA5 thing that won't work with Qt 5.12?

Switching to Qt 5.12 for all platforms means loosing macOS 10.10 and 10.11, no workaround (also loosing some Linux variants BTW).
Going back to Qt 5.9 for all platfoems means no NDVA, no workaround (and some Linux variants will go with whatever Qt comes as part of the distribution, so well may be in 5.12 or even later).

In reply to by Jojo-Schmitz

There is no question that there are write-arounds, and it is possible to code in ECMA 5 in an ECMA 6. That is not the problem. The problem is that any established Javascript programmer coming to plugin programming, on Windows, will unknowingly create plugins that fail on the Mac unless he or she is acutely aware of the 5/6 differences, and gets it 100% right without any way to test/check, or says, "I don't care about Macs", i.e., the platform-independence of plugins will become very, very iffy. If there were a way to tell Javascript "flag ECMA6 features (maybe there is?)" the way C++ compilers can be told what standard to abide by, this would be easier. but AFAIK there's not.

In reply to by BSG

I got that from the start. The alternative of either dropping macOS 10.11 and 10.11 or NDVA is worse though.
So restricting ourselfes to ECMA5 seems the far lesser evil for the time being, esp. as plugins are only used by a pretty small fraction of the user base.

Would this help to tell them appart?

try {
  var k = new Map();
  console.log("ECMA6 supported!!")
} catch(err) {
  console.log("ECMA6 not supported :(")
}
<qml>

In reply to by Jojo-Schmitz

No, that would not help at all. I'm not sure you see it yet. If a plugin coder consciously requires ECMA 6, he or she is saying, "I know that this script will not be usable on MuseScore on the Mac; too bad, Mac users! Get a Windows!" Such a check would merely simplify this behavior. Is that behavior to be encouraged? --As you observed, not one such feature is "necessary". But if he or she unconsciously uses ECMA 6 features (perhaps unaware of the issue we are discussing) it will generate plugin bug reports left and right when it fails mysteriously on the Mac.

In reply to by Jojo-Schmitz

How will you know? Who is going to study their plugin, look at its subtle run-time data handling etc and validate that it will work on the mac/ECMA5? We don't vet plugin-writers, either. How will plugin writers even know? Whose responsibility is it to make sure that this procedure is successfully followed?

In reply to by BSG

We (as a community of designers) have every right to say "accessibility on Windows is more important than new plugin writers writing plugins that fail mysteriously on the Mac", but we should acknowledge what devil we are dealing with.

In reply to by BSG

Right. And I'm pretty sure the above is the case, as for those users in deed of NVDA there is no workaround and it'd render the entire MuseScure unusable for them (a bBlocker), while here for the macOS users (which are, compared to Windows users, in the minority already) those that want to use plugins (which is just a fraction of them) won't be able to run plugins using ECMA 6 features (which most probably will be a very small number), which in turn be a minor nuicance at most would and with an easy workaround (rewrite to ECMA 5).

In reply to by Jojo-Schmitz

Actually, no, it's not an easy workaround for the person who has Windows MS with Qt 12. And it will not be up to the plugin "victim" to rewrite it, but the plugin author, who will have no way of testing his or her supposed downgrades when the complaints roll in. It will fall on experienced Mac plugin writers to do their work for them, a fraternity in which I barely count myself, and mandate a submission path for the latter ("us") to upgrade (or, rather, downgrade) the former's plugins. It's sort of like "Mac accessibility"; to the person not encumbered by Qt5 compatibility, they would not be so concerned about those who might be, especially when there is no easy path to ensuring it. At least I know that plugins that I write are upward-compatible of necessity.

In reply to by BSG

Well, it is up to the user to report to the author and/or rewrite the plugin or find someone else to do it, indeed.
But still this is only a very small minority, and the other 'workaround' is to just not use that particular plugin, simple as that.
I have yet to come across a plugin that is absolutly vital to be able to use MuseScore.

In reply to by Jojo-Schmitz

You don't need STL to write C++ programs. You can use strdup, malloc, and strcat and buffer overruns etc. But life is much, much better with STL. Same with C++11/14 features! Not needed!

You don't need the tempo-change plugin or my new articulation plugins, but they make all the difference in how the music sounds ("but we're not a performance engine!"). Fortunately, they work on the Mac. But we're entering a "segregated" plugin world, where which "caste" a plugin falls into cannot even be accurately and easily determined by its author unless he or she can verify full function of his or her features on a Mac. The whole point of using Qt is that it offers precisely such compatibility.

In reply to by BSG

Adding a single sentcence in the plugin docs shouöd be enough, along the lines of:
"For now restrict yourself to using only ECMA5 features, as currently at least for maxOS we're restricted to using Qt 5.9, which doesn't support ECMA6 and plugins using features from that won't run there."

In reply to by BSG

Heres a 5/6 issue that came up on another thread. Plugin object-wrapper objects are shared between concurrently-exposed (e.g. dock-type) non-cooperating plugins; it is thus undesirable to store properties in them. One could make a map of objects to further structure, except Maps of non-string keys or ECMA6 only. Thus, the workaround to the workaround needs another level of workaround, which can't even really be done (there is no write-around for object-keyed maps) unless the underlying wrapper system supplies some kind of help, or we ("what do you mean we?") decide, "oh, to hell with Macs -- not that many people use them anyway"; they can do without plugins.

In reply to by BSG

That's a bit extreme. Tons of useful features can and have been written without the latest esoteric language features, and I see no reason these can't continue to work, unless I'm missing something. So a few cool new plugin features of interest to a few folks might have to wait a bit, doesn't seem like the end of the world to me.

In reply to by Marc Sabatella

My argument earlier in this thread says that ECMA6 is not so new at all, and plugin writers are bound to no ethical code, and if allowed in 3.3 to use ECMA6 on Windows, will not think twice about using minor language features, like destructuring assignment and for-loop iteration over lists, and their code will work just fine, on Windows, and they might not care too much if the minority with Macs can't use it, for "restrict yourself to older language features", without a "-std=ecma-5 control argument" as in C++, will have little means or motivation to cater to people "stuck with Macs". And JoJo did hint that the Mac Minority was "less important", and that plugins themselves weren't all that important. This will lead to plugin "static castes", if I may.

In reply to by BSG

I never said that.
I merely said that the combined number of users that a) use a Mac and b) use plugins and c) want to use plugins using ECMA6 features are very, very, very few.
And that for those a) workarounds exist, as almost all Ecma6 features have Ecma5 equivalents and b) the number is users needing accessibility are more important and without any workaround.
I'm rather disappointed that you argue the way you do...

In reply to by Jojo-Schmitz

I'm sorry if I misinterpreted your position. Maps do not have an ECMA5 equivalent. And yes, accessibility is really important. There are no plugins using ECMA-6 features, so the argument that not many want to use them doesn't carry much weight. Frankly, I don't know how to solve this problem. It is a hard problem. I hope I don't sound like I have a secret or radical solution in mind. I don't. I'm sorry again if I'm arguing unreasonably. I'm just scared of chaos or downgrading of plugins as a direction. Accessibiity is really important, as is support of OS X 10/11.

In reply to by BSG

So, sounds like the ideal solution is to find the right Qt option to simply generate a syntax error on Windows if someone tries to use a new language feature not supported in Qt 5.9. Or failing that, then as you say, simply documenting it clearly that new language features aren't supported on all systems.

The point being, the issue is merely one of documentation - making it clear to plugin developers what is supported and what is not. I don't see how that's a big problem - we document lots of things, I don't see what makes this inherently harder to document than anything else.

Whereas the accessibility is one of functionality (as in, the entire program is entirely unusable). So yes, in the grand scheme of things, I think it fair to say that documentation issue is less important. Certainly, you don't make MuseScore entirely unusable to entire populations of people just because some plugin writer might not read the documentation (although I'm not sure how they'll manage to write a plugin if they don't!) and thus might end up writing a plugin that doesn't work on macOS and that such a plugin (which may or may not ever exist) would not work for macOS users. Plugin writers can write a lot of code that doesn't work well, there really isn't much we can do about that. But we want MuseScore itself to work for everyone, and there is something we can do about that.

Anyhow, to me this entire discussion really belongs in a separate thread.

Nice timeline.
It offers at least about a month of testing and correction time.
I look forward to the release of Beta.

My sincere thanks to everyone who has contributed.

Has any progress been made on making Musescore run faster? I remember it was one of the goals for the release of Musescore 3.0 that editing would be just as fast regardless of the size of the score.

Has there been any progress on that?

In reply to by Commander Continuey

A significant progress has been made and delivered in versions 3.0.5 (May) and 3.2 (July). There were no significant work done in the scope of the upcoming release.

Do you know something specific about the performance? Could you please share your observations on this topic? Maybe, separate forum thread is a good place to start that discussion. Ping me there via @

There is no documentation available yet for the new palettes, correct? I'd like to make sure I know how things are supposed to behave before I start reporting bugs…

In reply to by RobFog

I'm not aware of any yet. Feel free to ask questions (best to start a new thread). But FWIW, given that one of main purposes of the redesign ws to improve usability and specifically discoverability of features, to some extent, I'd say if you can't figure out how something works, that's kind of a bug in itself.

Do you still have an unanswered question? Please log in first to post your question.