4.3.0 release tag points to the wrong commit, resulting in file format version number incompatibility between released binaries and attached source code

[darix]

Issue type

Opening/saving issue

Bug description

was there any significant change to the file format that the bump was needed?

and if yes ... why not just tag 4.3.1 with the needed changes to that both OS can interoperate again?

Steps to reproduce

1. save file on latest windows build
2. try to open on linux

Screenshots/Screen recordings

No response

MuseScore Version

4.3.0

Regression

Yes, this used to work in a previous version of MuseScore 4.x

Operating system

win 11 and opensuse tumbleweed

Additional context

No response

[darix]

I could make it work again by patching the .mscx file in the zip archive:

@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<museScore version="4.30">
+<museScore version="4.20">
   <programVersion>4.3.0</programVersion>
-  <programRevision>5f36e74</programRevision>
+  <programRevision></programRevision>
   <LastEID>8686</LastEID>
   <Score>
     <Division>480</Division>
@@ -18,7 +18,7 @@
     <metaTag name="lyricist"></metaTag>
     <metaTag name="movementNumber"></metaTag>
     <metaTag name="movementTitle"></metaTag>
-    <metaTag name="mscVersion">4.10</metaTag>
+    <metaTag name="mscVersion">4.00</metaTag>
     <metaTag name="platform">Microsoft Windows</metaTag>
     <metaTag name="poet"></metaTag>
     <metaTag name="source"></metaTag>

[darix]

I found those values by inspecting a much older file. so it might be i wouldnt have needed to patch all fields.

[cbjeukendrup]

If a build of MuseScore fails to open a file containing <museScore version="4.30">, that means that that build of MuseScore is not 4.3 :)

And that turns out to be the problem. The source code tarball attached to the "4.3.0 release" on GitHub does not correspond with the 4.3.0 tag! The dates are quite curious too:

@Eism Is it possible to update the attached tarballs to reflect the 4.3.0 tag?

[darix]

those tarballs at the end are not manually added but autocreated by github based on the tag.

[darix]

i just created a new file and saved that. with the 4.3.0 tarball version of muse score:

rg -i '(mscVersion|programRevision|programVersion|museScore version)' *x
2:<museScore version="4.20">
3:  <programVersion>4.3.0</programVersion>
4:  <programRevision></programRevision>

[darix]

a better question would be "why do the provided binaries in the tag are 6 days younger than the tag and do not match the code" :)

looking at:

git log v4.3.0..5f36e74
commit 5f36e7453797401220f18f66530dcda4079b69ff
Merge: f037257dce cdb1fc7b7c
Author: Elnur Ismailzada <eismailzada@gmail.com>
Date:   Thu May 2 17:30:53 2024 +0300

    Merge pull request #22658 from mike-spa/increaseFileVersionNumberTo430

    Increase file version number to430

commit cdb1fc7b7c93ce8e0053362d38ee1c3d1d165d2d
Author: Michele Spagnolo <m.spagnolo@mu.se>
Date:   Thu May 2 15:48:14 2024 +0200

    Fix utests - 5

commit de58cc1c1953bf8552d2ec032f74e91a41d8aa29
Author: Michele Spagnolo <m.spagnolo@mu.se>
Date:   Thu May 2 15:47:34 2024 +0200

    Fix utests - 4

commit 231f4ae7768b93f1e1767a17dcc4d4a297daa6c1
Author: Michele Spagnolo <m.spagnolo@mu.se>
Date:   Thu May 2 15:46:42 2024 +0200

    Fix utests - 3

commit 567a7eb36dbfa367b8dba23e283fbaf7e22ca09a
Author: Michele Spagnolo <m.spagnolo@mu.se>
Date:   Thu May 2 15:45:20 2024 +0200

    Fix utests - 2

commit 8ee9a23ea9b96bb386bde69f8f9c794b33e2edd7
Author: Michele Spagnolo <m.spagnolo@mu.se>
Date:   Thu May 2 15:43:35 2024 +0200

    Fix utests - 1

commit 16f358cd23e0e30a8e6dd9a514a0f8f9dbf96f5a
Author: Michele Spagnolo <m.spagnolo@mu.se>
Date:   Thu May 2 15:37:37 2024 +0200

    Increase file version number to 430

well yes ... just tag 4.3.1 and lets call it a day. or should linux packagers just pull in this patch series?

[darix]

prepared this now for the openSUSE package:

osc diff | cat 
Index: musescore.changes
===================================================================
--- musescore.changes   (revision c59f7c84c5bedd3940c02ceef223d1f8)
+++ musescore.changes   (working copy)
@@ -1,3 +1,17 @@
+-------------------------------------------------------------------
+Sun May 26 22:06:23 UTC 2024 - Marcus Rueckert <mrueckert@suse.de>
+
+- Add patch series that was included in the usptream binaries but
+  not in the 4.3.0 tag:
+  https://github.com/musescore/MuseScore/issues/22984
+
+  0001-Increase-file-version-number-to-430.patch
+  0002-Fix-utests-1.patch
+  0003-Fix-utests-2.patch
+  0004-Fix-utests-3.patch
+  0005-Fix-utests-4.patch
+  0006-Fix-utests-5.patch
+
 -------------------------------------------------------------------
 Wed May  8 12:28:54 UTC 2024 - Marcus Rueckert <mrueckert@suse.de>

Index: musescore.spec
===================================================================
--- musescore.spec  (revision c59f7c84c5bedd3940c02ceef223d1f8)
+++ musescore.spec  (working copy)
@@ -62,6 +62,16 @@
 Source5:        README.SUSE
 # PATCH-FIX-OPENSUSE: openSUSE has qmake-qt5 qmake was reserved for qt4, which is no longer present
 Patch0:         use-qtmake-qt5.patch
+
+# PATCH-UPSTREAM: https://github.com/musescore/MuseScore/issues/22984
+# make it possible to open files created with official binaries in our build
+Patch0001:      0001-Increase-file-version-number-to-430.patch
+Patch0002:      0002-Fix-utests-1.patch
+Patch0003:      0003-Fix-utests-2.patch
+Patch0004:      0004-Fix-utests-3.patch
+Patch0005:      0005-Fix-utests-4.patch
+Patch0006:      0006-Fix-utests-5.patch
+
 BuildRequires:  cmake
 BuildRequires:  fdupes
 %if 0%{?suse_version} < 1560 && 0%{?sle_version} <= 150600

[cbjeukendrup]

Hah, it turns out the v4.3.0 tag is at the wrong commit (this was the RC commit and not the final release). That explains a lot. I don't know all the implications of "moving" (deleting+recreating) the tag, so I'm not going to mess with that. Maybe @Eism wants to do it.

The 4.3.0 branch does contain the correct commits, so maybe you could use that as a temporary solution.

Anyway, 4.3.1 will (hopefully) be released in a few days, so you could also wait for that.

[darix]

well I already updated our package with the patches and submitted it for inclusion. which now would mean that files created by an openSUSE user cant be opened by users on other linux distros. Which is annoying too. so yes hopefully 4.3.1 will be out soon and remedy the situation.

[darix]

also never drop tags. version numbers are cheap. just tag a newer version.

[darix]

@cbjeukendrup any thought on this patchh?

diff --git a/src/engraving/rw/mscloader.cpp b/src/engraving/rw/mscloader.cpp
index 544a00c655..c07fb4dff9 100644
--- a/src/engraving/rw/mscloader.cpp
+++ b/src/engraving/rw/mscloader.cpp
@@ -51,7 +51,7 @@ using namespace mu::engraving::rw;
 static RetVal<IReaderPtr> makeReader(int version, bool ignoreVersionError)
 {
     if (!ignoreVersionError) {
-        if (version > Constants::MSC_VERSION) {
+        if (version > 430 ) {
             return RetVal<IReaderPtr>(make_ret(Err::FileTooNew));
         }

that way I allow readying 4.30 files but will keep writing 4.20. this might give us the best interop for all cases no?

[cbjeukendrup]

But 4.3 files contain some new stuff that would confuse 4.2 builds, and thus we decided to bump the version number so that 4.2 would refuse to open those files. Unfortunately, this version number bump was done very close to the release (so close that the tag had already been created), while the changes that required the bump had already been made earlier, and are thus also included in the version from the tarball. Let's just wait a few days for 4.3.1.

[irwir]

Maybe a warning about newer file format should have been issued with an option to try reading anyway? Something like this was done for MS Office 2003 so it could try to read new docx format if user accepted possible incompatibility.

[cbjeukendrup]

The option to attempt opening too-new files was intentionally removed in 4.1 or 4.2. The reason is that this almost always results in scores with corruptions or oddities, that are not repaired when the user then opens the score in the newer version again. This puts a burden on the support team and the developers: they get all kinds of weird issue reports that nobody can reproduce and thus can't fix, which takes up a lot of precious debugging time that could also have been put into something useful.

[irwir]

The option to attempt opening too-new files was intentionally removed in 4.1 or 4.2. The reason is that this almost always results in scores with corruptions or oddities, that are not repaired when the user then opens the score in the newer version again.

Was it silently trying to read and then save it with a newer version tag? Then multiple issues might be expected.

Returning to Office 2003 example, it might briefly display a File conversion in progress box and after that it might show something like:

Since this file was created with a newer version of Word, it was converted to older format. The following changes had to be made:

• Function not supported in this version of Word were removed
• Template and some editing functions were altered

The user gets sufficient warning; file could be saved in older format. There should be no additional troubles for supporters.

[cbjeukendrup]

Was it silently trying to read and then save it with a newer version tag? Then multiple issues might be expected.

Uh no?

What I meant was:

1. Open too-new file in older version of MuseScore -> in the working memory of your computer, this score may now contain issues
2. Use "save as" to save the score to a new file -> the resulting file will contain the issues
3. Open that saved file in the latest version of MuseScore -> it may still contain issues, even though it's back in the latest version of MuseScore.

When someone then discovers the issues after step 3, and creates a bug report on GitHub, it's very difficult for us to find out what's going on with that score. We receive a corrupted score, but don't know how it got into this state, so can't reproduce it and thus can't fix it. This is a situation we just want to avoid completely.

Anyway, all of this is completely off-topic from this issue, which is actually fixed now that 4.3.1 is out.