4.3 vs. 4.4
I have been writing my recent files using the 4.4 nightly builds, only to discover that I can't open them with the 3.4 nightly builds. The system prompts me to use the 4.4 nightly builds instead:
This is rather alarming. Does this mean that when MS 4.3 is officially released, I still won't be able to use my files and will have to wait for the official release of MS 4.4 instead?
Additionally, I've noticed that the development of the 4.4 nightly builds has slowed down, while there are frequent updates for the 4.3 nightly builds. Could it be that 4.4 might be abandoned altogether in favor of 4.3? If so, what can I do with the files I've created in 4.4 if they can't be opened in 4.3?
Also, why is there a need to create this 4.3-4.4 fork? It's a bit confusing. Why not fully develop 4.3 first and then move on to 4.4?
Comments
4.3.0 is released (and 4.3.1 is imminent)
Using nightly build comes with risks...
In reply to 4.3 is released Using… by Jojo-Schmitz
@Jojo-Schmitz:
-- Thank you. So, since 4.3.1 is not realeased yet, the 4.3 line is not finished yet. If so, is there any reason why they have started developing 4.4 without having finished the 4.3 line first?
In reply to @Jojo-Schmitz: -- Thank you… by innerthought
Yes. This is common praxis and has been the case with MuseScore ever since
In reply to Yes by Jojo-Schmitz
Nevertheless, 4.4 scores cannot be opened with 4.3.
In reply to Nevertheless, 4.4 scores… by graffesmusic
Indeed
"Also, why is there a need to create this 4.3-4.4 fork? It's a bit confusing. Why not fully develop 4.3 first and then move on to 4.4?"
It's a bit like trying out a new recipe. You wouldn't scrap the old recipe until you are sure the new one works. Why would you have to wait until you had perfected the garnish on a cake before trying out a new tweak to the cake mix on another bake?
In reply to "Also, why is there a need… by underquark
@underquark:
"It's a bit like trying out a new recipe..."
-- Very good explanation! Thank you.
In reply to "Also, why is there a need… by underquark
Thank you so much for the information.
You can try export to music xml and see if 4.3 imports the vast majority of your work.
The reasons for 4.4 development:
MS 4.4 and future versions use Qt 6.2.4. ( much more recent and updated )
MS 4.3.x and “most” prior versions use Qt 5.15.x. ( kinda old )
Qt is a big part of the program.
It takes a lot of work to migrate over while adding new features. The parallel effort makes sense.
In reply to You can try export to music… by TDYama
@TDYama:
Thank you for this input.
"You can try export to music xml and see if 4.3 imports the vast majority of your work."
-- Yes, that's what I've been doing recently. It does, however, involve a lot of manual recovery like resetting all the mixer settings, getting rid of all red notes by creating new staves and copying the contents into them from the old red-notes-containing staves, and deleting and re-creating all the rehearsal marks one by one.
"Qt is a big part of the program"
-- I don't know what Qt is. Would be good if explained a bit.
In reply to Thank you for this input. … by innerthought
Qt basically is what allows MuseScore to build for and run on Linux, macOS and Windows and basically looks and works the same on these platforms
In reply to Qt basically is what allows… by Jojo-Schmitz
@Jojo-Schmitz: "Qt basically is what..."
-- Ah, I see. Thank you.
In reply to @Jojo-Schmitz: "Qt basically… by innerthought
On discord, there was a discussion on disabling version checking. You could try it. You change an .ini file and restart the program. You get a warning but just keep going and maybe can open the file.
It’s fun to try. See link here. Hopefully I am interpreting the discussion correctly. Set the option to true and see what happens. 😇
See the picture for the ini info. The discord link isn’t going to the intended spot so I deleted it.
In reply to On discord, there was a… by TDYama
of course that needs to be
disableVersionChecking=true, and in the project sectionIn reply to of course that needs to be… by Jojo-Schmitz
Thanks for clarifying.
In reply to of course that needs to be… by Jojo-Schmitz
Good thing you mentioned the projects section. I didn’t have a pre-existing entry. I added the line and was able to bring a 4.4 file into 4.2.1.
4.4 is nowhere near stable enough for real use yet. The nightly builds are for testing only at this point, and that probably won't change for at least a couple of months.
Not sure what you mean about 4.4 development slowing down - there are multiple new PR's on master virtually every day just as there have been for many many years. But every time there is a new 4.3.x release, resources that could have been spent working on 4.4 end up getting spent on 4.3.x instead, so there might be a slight did in 4.4 work any time a new 4.3.x release is being prepared.
As for why there is work being done on 4.4 at the same time as 4.3, as mentioned, this is totally standard practice. Just like at a restaurant, there are preparations for dinner being made while lunch is still being served. Or why a professor is making plans for next week's lessons while teaching this week's. Or why you save for retirement while also saving for the family vacation. It's the only way to make progress in an efficient manner.
In reply to 4.4 is nowhere near stable… by Marc Sabatella
@Marc Sabatella:
"But every time there is a new 4.3.x release, resources that could have been spent working on 4.4 end up getting spent on 4.3.x instead, so there might be a slight did in 4.4 work any time a new 4.3.x release is being prepared."
-- Yes, I think it was this thing that caused me to think that 4.4. development had slowed down.
"As for why there is work being done on 4.4 at the same time as 4.3, as mentioned, this is totally standard practice..."
-- Thank you, Mark, for this explanation. I kind of feel guilty for having asked a silly question—I should have researched this simple matter on my own first.