1.4.0 is asking for update to 1.4.230, but this is the newest version

[cambid]

Description

Mumble in Version 1.4.230 is showing version 1.4.0 and asking for a upgrade to 1.4.230.

I can confirm this with the official archlinux-package of mumble in version 1.4.230-2 which is build from https://github.com/archlinux/svntogit-community/blob/packages/mumble/trunk/PKGBUILD and a fresh build from https://github.com/mumble-voip/mumble/releases/download/v1.4.230/mumble-1.4.230.tar.gz with the three following commands:

mkdir -p build && cd build
cmake ..
make -j $(nprocs) mumble

You can see the problem in the following screenshot:

Steps to reproduce

1. Open Mumble
2. Help -> About. Check version number.
3. Help -> Check for updates. Check for a message in the chat-window.

Mumble version

1.4.230

Mumble component

Client

OS

Linux

Reproducible?

Yes

Additional information

No response

Relevant log output

No response

Screenshots

No response

[Krzmbrzl]

I am reasonably sure that this is because the package was built without specifying the BUILD_NUMBER variable (when invoking cmake). Thus the build number is defaulted to zero.

And the update mechanism is correct: 1.4.0 < 1.4.230 so that's why you are seeing the update prompt.

The correct build number can be obtained via the corresponding script in the scripts directory in the repo

[dvzrv]

@Krzmbrzl I am not entirely sure why a downstream is supposed to fetch a build number from a git repository while building (some build environments do not even allow network access during build time, and that's where Arch Linux is headed as well). It requires the caller to

• know the precise commit that the build number is supposed to be derived from (and we build from tarballs)...
• call a script on a website to fetch this meta information

  mumble/scripts/mumble-build-number.py

  Line 18 in 5be8b69

  query = "https://mumble.info/get-build-number?commit=" + commit + "&version=" + version

To me it does not make a lot of sense to have this extra step and it reads rather excessive. I am not aware of any cross-platform software that does this to have build number as their patch level version.
The version number should be set by the build system, not by some arbitrary manual extra steps that are also not documented in the build instructions.

When looking at the website's article about this I believe that the assumptions in the background section are not correct:

Mumble was always using the semantic versioning scheme which generally makes it really easy to know what to expect when switching from one version to another. While this is working great, using only the three common version numbers (major.minor.patch) poses a problem when considering snapshot builds. A snapshot build is essentially a beta-release for an upcoming release. Thus it has to use the same version numbers as that upcoming release. Thus, in order to get a unique versioning scheme, we had to make use of the fourth version number, that semantic versioning allows for. We called this the build number. This build number was just a number that was incremented with every build of the Mumble binaries that we performed. Thus a version could now look like this: 1.4.0.62 and the stable release would then simply use whatever build number was next in the queue.

This is what semver specifies as build metadata, but you have been using it as a fourth, dot-separated identifier in addition to semver. The supercollider project deals with this (for Windows) in a non-increasing fashion by adding a unique identifier to the build artifact (for stable versions and pre-releases) while adhering to semver:

• https://github.com/supercollider/supercollider/releases/tag/Version-3.12.2
• https://github.com/supercollider/supercollider/releases/tag/Version-3.12.2-rc1

In your terms this would denote to e.g. 1.4.0+230 and so forth, but for a stable release you do to not really require this at all. Your issue (at least judging from the text on the website) is because of pre-releases. For this the scheme would look e.g. as such 1.4.0-rc1+230.

Note, that the build number is tied to your build system and it might be reset when you lose your build system's state. As such I do not understand why you would want to have it at all in your versioning scheme, because it has nothing to do with the code, but all to do with your build artifacts.

For reasons I can not really understand at this point, the mumble project has opted to use a versioning scheme, that has nothing to do with semver and now uses an arbitrary build number that has nothing to do with the version, that builders of the software are supposed to retrieve manually.

Sorry, but the amount of overhead to establish what is to me a completely broken versioning scheme is not okay and it should be re-evaluated, as it breaks general assumptions about versioning due to failing to use semver correctly and making the lives of packagers harder for the sole gain to fix a problem that does not seem to even be a problem (separating the sources of the project from the build system of the project).

[dvzrv]

To get back to the actual topic of this issue:

Mumble in Version 1.4.230 is showing version 1.4.0 and asking for a upgrade to 1.4.230.

I built mumble using -D update=OFF which (at least according to the help text of that option) is supposed to setup mumble to not check for updates:

https://github.com/archlinux/svntogit-community/blob/c8bed7361725a3ebbc3eb63e4b0d328a2a6cfed9/trunk/PKGBUILD#L62

It seems that this still leaves the "Check for Updates" menu item in the "Help" menu. For distribution packaged versions this does not really make sense though. Is that something that can be also removed when setting the NO_UPDATE_CHECK definition?

mumble/src/mumble/CMakeLists.txt

Lines 807 to 809 in 5be8b69

	if(NOT update)
	target_compile_definitions(mumble PRIVATE "NO_UPDATE_CHECK")
	endif()

[Krzmbrzl]

1. The build number specification is mentioned for the installer instructions and should indeed be placed somewhere more prominent (as well)
2. You fetch the tarball from online, so you can also fetch the build number at the same time and then continue to do your build offline. So the network access shouldn't really be a problem
3. The versioning scheme as-is does conform to SemVer. All things that are backported to the 1.4 branch are in fact backwards-compatible bug fixes, so increasing the patch version with every such change does not violate any semver requirements that I am aware of. You can view at as a more rapid "release cycle" where technically every new PR that gets merged gets immediately released (formally)
4. Using the build number as the patch version was the only option that we saw that allowed us to have inter-release "releases" (aka snapshots or nightlys) that don't mess up on Windows (aka: allow the installer to upgrade as expected). The version fields for the respective Windows things do (to our findings) not allow for any text input and as such a version scheme like 1.4.0+230 is not possible (to our knowledge). If you know of a way to make that all work, please share it with us
5. The build number being tied to the build system is kinda correct, but that doesn't strike me as a real problem. Should it ever get lost, we can simply restart it with a number high enough as to not create duplicate versions. After all semver does not require continuous version numbers (to my knowledge). And I wouldn't say that the build number is related to our build artifacts, since the build number uniquely identifies from which commit a given version of Mumble has been built. This is independent from our artifacts.
6. -Dupdate only changes the default of the setting but does not remove the update check functionality from the client (see its documentation and also Don't hide the setting if no-update config was used #4138 and Show warning message for enabling update checks with no-update config #4182) - the possibility to completely remove update checks has been removed.

EDIT: On the topic of building from source tarballs. As far as I am aware this is a bit flaky anyway, since the source tarballs as created by GitHub do not contain any submodules, which we depend on for building Mumble.
Therefore, I would advise to simply use git to checkout the respective branch/tag in the first place, which also solves the issue of not knowing what commit you're currently at.

[Krzmbrzl]

As an aside: You don't need the script at all if you are only building a released version. Just copy the build number right from the version you are building and everything should work out as expected.