-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MU3] Fix GH#7449: Almost everything suitable for 3.6.3 or 3.7.0 #9000
Conversation
f655f6b
to
4967716
Compare
828baec
to
27d68f4
Compare
I'd appreciate if the original authors of the PRs/commits I've included in this PR would double check whether I did it correctly. In (more ot less) chronological order: |
looks fine! |
c75cc29
to
6b514fd
Compare
300daba looks good |
#311792 looks good to me, thanks |
Thanks, I guess with that you can close your PR #6693 |
#6095 looking good thank you |
I have not done a good job keeping up on Discord. Is a 3.6.3 being seriously considered? If so, to me this list is too long by a factor of 10 or so. I see far too much risk that this breaks something and then requires 3.6.4. If we're OK with that, fine. But otherwise, I would prefer to see 3.6.3 just include fixes for the top 10 most serious regressions that have low-risk fixes. Anyhow, I'd like to understand the context a bit more. |
646283b
to
84720e5
Compare
This reverts commit d200716. It seems no longer to be needed, most probably got obsoleted by later changes to SMuFL or Bravura/Petaluma See also https://musescore.org/en/node/344717#comment-1175789
1975bf3
to
840a4e3
Compare
Updated version of musescore#5762
Further investigation shows that the current MusicXML importer contains two kinds of MAX_STAVES sized data structures: the voice mapping data and the per staff octave state. It also seems that in the current MuseScore releases (both 3.x and 4.x) MAX_STAVES is used for the maximum number of staves in an instrument template only. It obviously does not limit the actual number of staves in a part. The structural solution would be to make these MusicXML importer data structures dynamically sized. A crude solution is to create a local fixed (larger) size. This here is an experimental 3.x version of the last one, it allows up to 6 staves per part.
Force building 32-bit Windows on GitHub CI using Qt 5.9.9 for now, as there is no 5.15.2 package available currently for the GitHub CI builds. Also allow "Save online" even from an unstable build in GUI and on the commandline. Temp. measure... needed only as long as there is no 'official' release (which may mean forever). Ignore a file generated on a master build same way it is ignored non in the master branch too. Just eases the switching between master and 3.x Fix some GitHub actions warnings reg. deprecated Node.js 12 vs. 16 Fix vtests build using a similar method as the mtest. Doesn't work, so back to 5.9.8, for Linux, for now... Trick musescore.com to allow save, by claiming the score to stem from 3.6.3... Change Linux builds to use Ubuntu 20 and partly sync with master's ci_linux_mu3.yml
840a4e3
to
0a9d057
Compare
I'm sorry, but I'm going to close this PR for the following reasons:
I would recommend creating a fork and continuing the work there. Thanks! |
I of course do have a fork (which is what this PR is made from), but not the GitHub CI workflows set up to create the artifacts, that's what I need the PR for. |
You could just fork from my work, see this fork: https://github.com/lyrra/MuseScore it has its own CI workflow which produces weekly Musescore3 packages. The packages are for linux and windows (mingw). |
RomanPudashkin dixit:
I would recommend creating a fork and continuing the work there. Thanks!
This is an official endorsement that the work as it is, without
renaming, can be continue in a forked repository? That’s good
to have.
Thanks,
//mirabilos
|
Great! Could you add an release step, so the artifacts are released? This enables people who are not logged into github to access the packages. |
You mean something like this? |
Yes, something like that :-) |
Mostly resolves #7449 (i.e.: it includes the vast majority of the PRs listed there, but not all. Contains far more than listed there too)
Submitted mainly to get the development builds from GitHub CI (AKA artifacts, see the corresponding checks), for Windows (64-bit and 32-bit, no PortableApp unfortunately), Mac and Linux (64-bit AppImage) and also to get the vtests to run (which are expected to fail, but I'm curious in what way. Edit: As far as I can tell the vtests failures don't show any real failures, only changes for the better, but see for yourself, from the artifact of the corresponding check), and also for the mtests of course (which I expect it to pass with flying colors. Edit: indeed they do).
If you want to download and test, see https://github.com/musescore/MuseScore/wiki/Downloading-and-running-test-builds#Downloading-Builds-from-Pull-Requests, needs some adjustment for MuseScore 3 though.
Edit: Actually, as the PR got closed now, see #9000 (comment).
Yes, it really is more than 360 commits (and still counting)...
All this on top of the 81 commits that the 3.x branch is ahead of 3.6.2 already.
So this indeed feels more like a 3.7(.0) rather than a 3.6.3, but as long as such a thing is not planned for, nor another PR for such a much smaller 3.6.3 exists...
Edit: I made up my mind and made it a 3.7.0 now ;-)
(Might also get named 3.9.0, to make clear that it really is the last minor release before/below 4.0)
From PRs against the 3.x branch (not merged into it yet):
[MU3] [DAISY] backport of master fixes to 3.x #7870, part 1 / [DAISY] Fix #298147 MusicXML: Handle measure number offsets #7617(But reverted again later, due to to many mtest failures)and on the commandline. (just for testing),
Not included so far:
[MU4] fix #295235: Same Beat and Measure (Select All Similar Filter) #5637 (Despite its title it is rather based on 3.x)[MU4] FIX#301367 - exclude ties from System::scanElements() #5735 (Despite its title it is rather based on 3.x, causes a regression: ties are not shown anymore at all, @sidewayss?)Adding ability to divide Fraction by integer. #6080PRs backported from master (merged and not yet merged ones):
computeFirstSegmentXPosition()
)physicalLine
method #9309continueSymbol
imports empty in 3.x, crashes in master #10793 (2nd part only, 1st doesn't apply to 3.x)std::gcd()
#11560 (the 2nd commit only, the 1st requires C++17)Not included so far:
added option to always layout the title on the same page as beginning of the score #9092 (UI missing though, seems to need more work, but porting it doesn't seem to make sense anyhow)Fix grip size (replicate MU3 behaviour) and make it easier to select grips #9414 (apparently not needed, not even partly)PRs against the 3.6.2_backend / 3.6.2_backend_musicxml branches (all merged into those). See also #9581 for a forward port of those to master:
[MU3 Backend] Eng-53: Horizontal spacer for FretDiagrams #8296, part 1(causes a regression, so it got reverted (much) later)Not included so far:
[MU3] Fixed adding a separator between data when generating pngs and svgs #10740(reverted by [MU3] Backend json fix #10816)[MU3] Backend json fix #10816(reverts [MU3] Fixed adding a separator between data when generating pngs and svgs #10740)There are still some PRs not (yet) migrated into this one here (see above) and also some open issues (i.e. without a PR or otherwise known fix), see #7449.