Simplify (build/packaging/deploy) code around version number and stable/unstable

We have quite a lot of code that does something with version numbers and especially "release channels" and "stable/unstable":

Version number and label

• version.cmake is the source of truth for the version number itself (major.minor.patch). But it also concerns itself with the version label.
• the deploy workflow can also set the version label, but it refers to it as "release type", and doesn't pass that to the actual build. So the actual build uses the value from version.cmake, rather than the value specified to the deploy workflow, which is only used for creating a tag.

Stable/unstable

• version.cmake refers to MUSE_APP_UNSTABLE, but always sets it to ON.
• Actually setting MUSE_APP_UNSTABLE happens in SetupConfigure.cmake.
• MUSE_APP_UNSTABLE is used to determine
  • the DESKTOP_LAUNCHER_NAME (?) and some other things for AppImage packaging
  • whether a git_date_string gets appended to the CPACK_PACKAGE_FILE_NAME (?) on Windows
  • the QCoreApplication::setApplicationName, which determines where user settings are stored
  • whether " Development" gets appended to BaseApplication::appTitle()
  • which channel to use for multi instances inter process communication

Is prerelease

• Besides MUSE_APP_UNSTABLE, we also have MUSE_APP_IS_PRERELEASE.
• This is also referred to by version.cmake but always set to ON, and then set to a real value in SetupConfigure.cmake.
• MUSE_APP_IS_PRERELEASE is used to determine
  • some things for the Windows installer, and nothing else; looks like MUSE_APP_UNSTABLE could have been used just as well

Release Channel

• As if that wasn't enough yet, we also have MUSE_APP_RELEASE_CHANNEL.
• MUSE_APP_RELEASE_CHANNEL is set in version.cmake, based on MUSE_APP_BUILD_MODE, assuming that that has a lowercase value.
• MUSE_APP_RELEASE_CHANNEL is also set in SetupConfigure.cmake, which sets it to entirely different values. However, it follows the same pattern as version.cmake does, also based on MUSE_APP_BUILD_MODE, but by first converting that to uppercase, which results in yet another BUILD_MODE variable.
• MUSE_APP_RELEASE_CHANNEL is used to determine
  • the "short prod name" in the Windows installer, and the ProgIdSuffix

Install suffix

• Especially on Linux, there is yet another variable, namely MUSE_APP_INSTALL_SUFFIX. This is not defined in CMake, but passed in via the CI scripts.

App name / title

• We have two different variables MUSE_APP_NAME and MUSE_APP_TITLE. Not great, but okay, this is a necessity because internally everything is still called MuseScore (without Studio) in order to reuse user settings from MS4.3/4.2.
• We also have MUSE_APP_NAME_VERSION and MUSE_APP_TITLE_VERSION. These appear to be the MUSE_APP_NAME/TITLE variables with a space and the major version appended to them. That's not quite clear from the name though. I propose to get rid of such variables. That might mean we have to type more characters in some places but at least it provides clarity.
• For "dev" and "testing" builds, we additionally append the "release channel" to these variables.
• Besides what you would expect, MUSE_APP_NAME_VERSION also determines:
  • the default install location on Windows
  • some Linux packaging things that I don't really understand but whatever

That was mostly everything about things inside the build scripts. Next up: the CI scripts.

Version number, again

• A lot of new version number formatting logic has appeared in make_tag_name.sh, and some extra check logic in deploy.yml. This is probably not really avoidable, but we must watch out that it doesn't duplicate, or get out of sync with, other places where we do version number logic.
• As said, the deploy script concerns itself with version labels and version label numbers (the '2' in 'beta.2'), but doesn't pass this to the actual build.

Build modes

• In the CI workflow files, we allow four build modes: devel, nightly, testing, stable.
• That goes through some shell scripts and env files, to finally land in the build ci script, which decides MUSE_APP_BUILD_MODE. I'm not sure if the current situation with these env files is as simple as it can be, but in principle nothing is really wrong here.

Summary: quite a lot indeed.

Proposed solution

We should primarily remove redundancy/duplication.

• Let's keep version.cmake the single source of truth for the version number
• Let's make deploy.yml the single source of truth for the version label, e.g. alpha.2, beta.1, rc
• Let's unify "unstable" and "is prerelease"
• Let's think about whether we really need MUSE_APP_RELEASE_CHANNEL
• Let's investigate what MUSE_APP_INSTALL_SUFFIX is doing exactly, and whether we can potentially unify it with MUSE_APP_RELEASE_CHANNEL
• Let's see if we can unify the "devel, nightly, testing, stable" with MUSE_APP_RELEASE_CHANNEL/MUSE_APP_INSTALL_SUFFIX

There are also some almost-design questions:

• We should do an audit of how the version information is used in the filenames of installers and executables, and unify/simplify where possible

• We should think about how we want version information to be displayed in the UI

• We should think about which "release channels" we want to distinguish for installing builds alongside each other. The current situation is not quite consistent:

  • For the user settings folder, we distinguish only we only distinguish release-vs-prerelease
  • For the Windows installer location, we distinguish Dev, Testing and Release, where Dev is used for PR builds and nightly builds

  Just release-vs-prerelease might be enough, but we could also consider distinguishing all four channels (dev for PR builds, nightly for nightlies, testing for alpha/beta/rc, stable for releases). Anyhow, we should think about how this will be presented in the UI and in the settings/install locations.