Upgrade path between different environments (esp RC to GA)
(I call Alpha / Beta / Release Candidate & General Available ”‘Environments”)
I installed RC and was unable to update RC to GA, even though (on macOS) they use the same “MuseScore 3” directory, e.g. GA is clearly built to replace RC, whereas Beta and older had a separate directory.
My request is that RC and GA use the same repositories so that one can upgrade from RC to GA. If something is good and stable enough to be called a release candidate, surely one would trust the built-in upgrader to do a seamless upgrade from RC to GA.
If there is a development life cycle model best practice or software architecture reason to not allow this, I would like to know about it.
Comments
So, you want to make update from RC to GA available, don't you?
In reply to So, you want to make update… by Anatoly-os
Yes please. If/when there is a 3.0.1-RC, the auto update mechanism will update it to 3.0.1 (GA/final) when released.
And at a minimum, the "Check for update" functionality of the RC should NOT say "No update available" while there is clearly one being the released version.
In reply to And at a minimum, the "Check… by frfancha
Exactly. I consider that very counter-intuitive, If it were to be decided that for whatever reason RC will/should not auto-update to GA, the only way this would be acceptable if the user were very clearly told somewhere on app startup that this RC will not be automatically updateable to GA but that the user has to do a manual upgrade (but hopefully we are not going that route).
In reply to And at a minimum, the "Check… by frfancha
Very true, but that bird has flown for 3.0 RC.
Feel free to file an issue so it gets fixed for the next alpha/beta/rc round
In reply to Very true, but that bird has… by Jojo-Schmitz
Actually no. I can update the Autoupdater config so that RC users will be able to update to GA (with one more installed version of MuseScore3, because official installer won't replace the RC's registry keys).
Btw, the decision was based on a simple assumption. Alpha, Beta and RC are ONLY for the users who are ready to test the non stable (non official) editor. For the ones who clearly understand the consequences of using any kind of pre released versions. This type of users can easily understand, that RC won't be updated automatically and they understand how to download and install official builds to replace the RC if necessary. MuseScore 3.0RC will be updated to MuseScore 3.1Beta most probably which is ok.
That is why internal implementation includes three channels for the update: dev (MacOS only, any nightly builds suggests update if current version is behind current master), testing (both, MacOS and Win, all flavours of testing builds including RC), stable (both MacOS and Win, available for all users).
Do you still believe we need the possibility to update the RC to GA? I don't.
UPD: Added "phases" according to Riaan's issue. If minor releases (3.X) is a matter of few months, it makes sense not to remove RC manually, but keep it for major feature updates testing purposes.
dev (for only macOS nightlies testers and devs): revision1 -> revision2 -> revision3 -> ... -> revisionN -> revisionN+1 -> ...
testing (for Win and MacOS Beta testers): 3.0 Alpha -> 3.0 Beta -> 3.0 Beta Update -> ... -> 3.0 RC -> 3.1 Beta -> 3.1 Beta Update -> 3.1 RC -> 3.2 Beta -> ...
stable (for all Win and MacOS users): 3.0 -> 3.0.1 -> ... -> 3.0.N -> 3.1 -> 3.1.1 -> ...
In reply to Actually no. I can update… by Anatoly-os
MuseScore 3.0RC will be updated to MuseScore 3.1Beta most probably which is ok.
No it is not, as all 3.x instally on top of one another, in the same place. So you can't stay on 3.0 RC and install 3.0GA, and so hope to get 3.1Beta installed over RC, but keep 3.0.x GA
In reply to MuseScore 3.0RC will be… by Jojo-Schmitz
Why? I changed the GUID of the installer so if you rename the installed RC directory to MuseScore3RC, then install MuseScore3, everything will work.
The only thing I need to keep aligned for the future RC/Beta releases is correct installer GUID.
In reply to Actually no. I can update… by Anatoly-os
@Analoly-os, I think you make good points. The people obviously paid attention to the site to know the Beta was released, so they should be paying enough attention to know the GA is released. I think most of these people would also be willing to help with testing future RC's. This discussion was likely started because a few people only checked for updates from within the program and failed to update to the GA, then reported fixed bugs.
In reply to @Analoly-os, I think you… by mike320
<< The people obviously paid attention to the site to know the Beta was released, so they should be paying enough attention to know the GA is released. >>
Perhaps, and ?
"The people" as you say have been used (and promised so) to have their beta automatically updated, or updated at demand by check for update.
And without any mention anywhere that this could be false, this "check for update" function just ignores the GA and declares "No update available".
So "The people" just think they work on the GA version (if they have seen on there is one) while their are clearly not ; or think that the GA is not available yet (if they don't have seen it yet on the web site).
The fact that the beta (or RC or whatever) doesn't allow you to update to GA and requires a manual download is annoying and should be changed to be more user friendly and logical, but that's not the main problem.
The main problem is the complete absence of any message/warning in the check for update functionality about the existence of a next version, making normal users thinking they are using the most recent and bug corrected version while they are not.
In reply to Actually no. I can update… by Anatoly-os
What I'm wondering if if it is possible/makes sense to have sparkle configured as testing and include GA in the chain?
Speaking personally, I was on beta, which nicely upgraded to RC, but then if/when I wouldn't follow the forum/announcements keeps me stuck on said RC. That means that if I keep testing and/or reporting, at a given point someone such as Jojo will respond to my report that I should update to the release manually.
However, if I do that, I then have to check back regularly again to be aware when a new alpha/beta is available to put me back in the testing channel.
Simply having the GA published into the testing channel as well, but keep your configuration on the testing channel would be so much more helpful.
In reply to What I'm wondering if if it… by jeetee
It is technically possible, but anatoly-os has given his reasons for not wanting to do it on this thread, which I am willing to accept. Also, on macOS your development version goes to MuseScore 3 Development, which would become a GA install if it were allowed to auto-update to GA.
E.g. as an alternative to auto-update I am pushing for some notification when the GA arrives, #281662: Check for update on RC: "No update available".
In reply to It is technically possible,… by Riaan van Niekerk
Yes, such a notification is really a must. Autoupdate not happening I can understand and accept.
In reply to And at a minimum, the "Check… by frfancha
Once the GA is released, anyone running any pre-GA (Alpha, Beta, RC) SHOULD be told that a GA is available if they check for update.
Auto-update can update like to like phases within the same series (3.y.z)
And maybe even between pre-GA, e.g.
Issue logged: #281614: Support auto-update between different phases, e.g. RC to GA
If at first you do not succeed, try another angle: #281662: Check for update on RC: "No update available"
I made an update to 3.0.1 available for RC users on MacOS. Working on the update for Win users.
In reply to I made an update to 3.0.1… by Anatoly-os
MuseScore 3 RC is now able to be smoothly updated to MuseScore 3.0.1 via the autoupdater.
The update process should go smoothly, but copy Documents/MuseScore3 directory to a safe place before updating to prevent occasional wiping data.