Run Minetest update checker on startup

[SmallJoker]

However, the version checking is not optimal (relies on MINOR.MAJOR.PATCH) and GitHub seems to limit the API page calls (source). core.get_version should probably also be extended by a is_dev_build field to get around the ugly detection.

See #7629 (comment) for the current status and testing instructions.

[rubenwardy]

This, unfortunately, doesn't help with the biggest offender - Ubuntu. I've heard their policy was to remove update notifications and such from programs, but I can't find a citation for this (although I have seen one in firefox). Maybe they won't notice? :D

[ClobberXD]

It'd be nice if the update check interval can be selected from a pre-defined set of choices like so

• 1 day
• 1 week
• 1 month

[Calinou]

This, unfortunately, doesn't help with the biggest offender - Ubuntu. I've heard their policy was to remove update notifications and such from programs, but I can't find a citation for this (although I have seen one in firefox). Maybe they won't notice? :D

That is indeed the policy of most distributions (including Debian and Ubuntu). It makes sense from their point of view, as users are not supposed to download Minetest directly from minetest.net according to them.

It'd be nice if the update check interval can be selected from a pre-defined set of choices like so

Is it really necessary to add one more configuration option just for this? We have a lot of them already. I think it would be enough to have a single boolean that controls whether updates should be checked daily.

[rubenwardy]

That is indeed the policy of most distributions (including Debian and Ubuntu). It makes sense from their point of view, as users are not supposed to download Minetest directly from minetest.net according to them.

It would be nice if they also didn't provide an outdated version of a networked program :/

[ClobberXD]

Is it really necessary to add one more configuration option just for this? We have a lot of them already.

I feel that the user should have control over how often MT checks for updates, and I don't think one extra drop-down would do any harm. :)

[rubenwardy]

I don't think there is a need for the setting, personally. It adds more complexity and more settings is more things to test

[nerzhul]

Just use the github last release API instead of full release API:

#7629

[rubenwardy]

We should not rely on the GitHub API as we may not use it forever. We could use the Github API in Jekyll to automatically make a JSON file with the latest release, this would be future proof

[Fixer-007]

"was found" somewhere in the dungeons of the internet?

[ClobberXD]

"A new Minetest version..." maybe? Sounds better and more like a full sentence... :)

[orwell96]

The "never notify me again" tickbox is a bit misleading IMO, it should read "don't notify me on future updates" or so. I wouldn't expect from such a checkbox that it disabled notifications for future updates.
Also, update notifications should be disabled in builds that are neither run_in_place nor installed by the wix installer #6153, by setting the default setting this way

[ghost]

I think not good, I suggest : Add a news column in main menu is not possible ?

[SmallJoker]

@orwell96

is a bit misleading IMO, it should read "don't notify me on future updates"

That's also a possibility, will adjust the PR accordingly.

update notifications should be disabled in builds that are neither run_in_place nor installed by the wix installer #6153, by setting the default setting this way

Why? Referring the users to the official download page covers all (or at least should) platforms which we support. Official repositories tend to be outdated quickly and people can tick the checkbox once on the initial startup to never get a notification again.

@MrChiantos This is possible but wouldn't provide enough new and helpful information since the (half/)yearly updates would be likely the only content.

[orwell96]

update notifications should be disabled in builds that are neither run_in_place nor installed by the wix installer #6153, by setting the default setting this way

Why? Referring the users to the official download page covers all (or at least should) platforms which we support. Official repositories tend to be outdated quickly and people can tick the checkbox once on the initial startup to never get a notification again.

You're right, that suggestion was bullsh*t...

[t4im]

How about setting the defaults via cmake flag, with it defaulting to no updates?

• During release builds you can flip this on, so that the distributed prebuild releases come with the check enabled
• Distributions building their own releases can enable or disable updatechecks according to their policies
• Anyone building a dev build from source would automatically skip it (if you build from git, you are already in full control of the version you are building anyway, especially if you intentionally build an older version for testing)

This would then work as wanted without depending on having the right minetest.conf ready or additional version information passed around.

[SmallJoker]

@t4im Thanks for your suggestion. I added the CMake config UPDATE_CHECKER_DEFAULT which allows distributions to disable the checker by default. Defaulting to false for in-development builds seems however wrong, because there are people who use the Windows development builds from the forums or Linux users which take the binaries from the daily PPA.

[t4im]

Well, anyone doing the windows development builds and daily ppa builds could flip this on as well.

The idea behind the default was that someone cloning the git repository to compile it themselves would have a default of no-updates without having to opt-out.
But anyone downloading a prebuild binary from someone else could have it enabled by the person doing the build (or more likely the CI system configuration) flipping the updates on.

This ensures that no one has to switch it on and off all the time (assuming CI systems being used for daily development builds)

[Fixer-007]

BTW, what is the difference between "OK" and "Remind me later"?

[Desour]

I think, "Ok" means something like "OK, I understood, don't tell me about this version again.".

[nerzhul]

i think it can be good to embed the update API in server list or another such program which will cache the github API calls for 1h or more, and control the backend API in case of at a point a migration outside github will be done (i don't say in the next year, but maybe at a point github will have too many problems).

[rubenwardy]

This is done from my point of view, it's just that Android error that needs to be fixed

[SmallJoker]

Maybe rebasing fixes the Android issue? 🤔

I also squashed closely related commits to keep the overview.

[sfan5]

If this is broken on Android and we want it for 5.6 maybe it could just be disabled on there? Most users get MT via an app store anyway (which takes care of updates).

[sfan5]

Actually the variable is merely missing here:

minetest/android/native/build.gradle

Lines 13 to 17 in 6df69f9

	arguments '-j' + Runtime.getRuntime().availableProcessors(),
	"versionMajor=${versionMajor}",
	"versionMinor=${versionMinor}",
	"versionPatch=${versionPatch}",
	"versionExtra=${versionExtra}"

[SmallJoker]

Nice catch, thank you @sfan5.
Checks on Android are now disabled, as requested.

[Niklp09]

works:)

[sfan5]

I pushed a commit that fixes some potential issues (and moves a few lines around for no reason) and tested the feature. In principle this has my +1.

Just two things:

• can we make the dialog a bit bigger? It doesn't need to be so tiny
• what happens if the http request takes a long time and the player is already in e.g. the world creation menu?
  • the dialog should probably simply be not shown (it can be shown when the next check happens)

[sfan5]

The following should work to detect if we're still in the main menu (and not some dialog):
if not ui.childlist["maintab"].hidden then

Testing code:

--- a/builtin/mainmenu/tab_about.lua
+++ b/builtin/mainmenu/tab_about.lua
@@ -141,7 +141,10 @@ return {
        end,
        cbf_button_handler = function(this, fields, name, tabdata)
                if fields.homepage then
-                       core.open_url("https://www.minetest.net")
+                       core.handle_async(function(_) os.execute("sleep 5") end, "",
+                       function()
+                               print(dump(_G.ui))
+                       end)
                end
 
                if fields.share_debug then

click the homepage button, switch to some other part of the menu and see what the internal state looks like

[sfan5]

Works.