Notifications of new engine versions.

[rubenwardy]

I'd like your opinions on this. This issue is not about updating automatically. Please be open minded about this and consider the end-user, rather than just objecting due to it not being any use to you.

Advantages:

• Beginner players may not know that they have an older version. Players may never check the forums or website (due to lack of interest or parents not allowing).
• Alerting of security issues in current version.

Disadvantages:

• Support for forks. A solution would need to have the ability to be disabled via minetest.conf.
• Overhead. It could be combined with the serverlist, but not so good for forking. (Forks may want to use the same serverlist, but notify about different versions)
• Potential for tracking (not really an issue, serverlist already exists)

This should be considered low priority.

[nerzhul]

In fact you tell us to check at client launch if there is a new client version, right ?
Then i think we can use curl and master server to check the client version and notify about a new version, right ?

[est31]

This is for windows? Linux and other OS's have package managers. And for windows, we should maintain our presence in the chocolatey repo. Then we point people at that, and stop offering separate downloads, as we do already for linux.
This would also fix the missing installer "issue" some people have.

[Lymkwi]

Linux and other OS's have package managers.

Indeed, but most of Linux distributions have not updated their packages. They sometime proposes versions old from 1 year. Some of them are still updated, and the PPA repository, for Ubuntu, is an example of solution. The solution I use the more to check for update is simply a local clone, which I update with git pull. For Windows users it would be good to be warned that a new version existes.

[SmallJoker]

The idea is good. There's already a way to change the server list URL, so why not add a setting for the news/update checking stuff?
It would be required to send the Minetest version to the update checking URL. I think indev builds should be only notified if there's a new stable.

One disadvantage more: How would you notify older clients?

[Lymkwi]

Older clients cannot be warned, that's a problem, but with 0.5 release, people will be forced to upgrade their clients if server upgrade. So if this is added before 0.5 release, older clients would be a smaller problem.

[apoleon]

It depends on the release cycle of Linux distributions if a version of Minetest can be included or not. You can't always have the latest bleeding edge software and at the same time demand rock stable long term releases. There is a trade-off and the correct way to deal with this issue is to upgrade to a newer release of Ubuntu or to request backports. You can also choose to install a rolling release distribution such as Debian testing or Debian unstable where you get the latest software but where you obviously have to deal with more bugs than in stable releases.

As one of the Debian maintainers for Minetest I recommend to make every "update check" opt-in because otherwise many would consider this a privacy breach and in the worst case this feature had to be disabled.

[Zeno-]

I recommend to make every "update check" opt-in because otherwise many would consider this a privacy breach

Yes, that is a good point

[rubenwardy]

It's not technically a privacy breach, no information is sent to the server. Only the latest version string is sent from server to client.

[twoelk]

couldn't the client just request some informative string from the github minetest repository and compare that with some code snippet of the same purpose in the local version?

[rubenwardy]

That is a possible solution. You'd have to add a "stable" branch and maintain it. Unless you could get the latest version from Github reversion page.

[rubenwardy]

Yes, there is a JSON version API: https://api.github.com/repos/minetest/minetest/releases

[est31]

There is already a "privacy breach" as the version is sent for the master list (which is enabled by default). I don't see how this would worsen the current situation, rubenwardy has this already pointed out inside the issue description @Zeno- @apoleon. I still don't see the advantage in such a tracker. The version adoption problem minetest has is thanks to android forks which don't update, not because of (mostly) desktop users. #2508 would have tackled this, but apparently people didn't like it.

At least server's lua should be abled to know which network protocol version the client uses, so that it can inform clients when the network protocol version is too old. This is fork-agnostic, and every fork can chose version numbers for the software itself as they want. If the app can't manage to update to new versions, then its in the interest of server owners to tell people they should move the app. I am admin of a server, and often my players can't even answer which app they use.

I don't see why we should treat a rebranded version with ads and a paywall added, and whose "creator" doesn't even have the time to update it, like a serious fork like freeminer. Those apps have age old bugs which are long fixed in minetest, but are still inside those forks ("please all, stop talking, I want to craft"). I'm not fork-unfriendly, I'm unfriendly against unmaintained software.

[Zeno-]

@est31 I think you misunderstood my comment. I merely said that apoleon had a point. Apart from that I have no objection whatsoever to this feature request.

[twoelk]

why should my client send any information? (besides what floats around in the chatty internet anyways) The client just needs to collect information - not send.
It just needs to contact to some place that offers some information from which it can conclude what the current version may be, if we do not have any place that clearly states such information. I am pretty sure though that github offers such information for computing at home and not on some remote server, without having to disclose to the net what I have stored locally. (as rubenwardy hints)

So all I do is retrieve some info without telling anybody what for. Then I close the connection and compare the information with what I have locally and from this magic mumble jumble my app does at home, secretly, in hiding, without telling anybody in the internet, I build a message and tell the local user and only him whether the version on github differs from the local version. For those using a stable version it could just compare that and for the bleeding edge users it could state something like: "your locall version is 100 commits behind github" Then the user could decide upon his update strategy.

[est31]

@twoelk It is true, the client doesn't have to send information. I just pointed out that it already sends that information at another place. Also note, that I don't think its a good idea to synchronize this over github. Github might be great right now, but perhaps one day they do something we don't like, and we want to move.

[rdnuk]

the most reliable way would be to send the latest version string to the client along with the server list. the client wouldn't need to give out any more information than it already does because it can do its own checks as stated by others above.

[ghost]

I like how youtube-dl has done it where you run youtube-dl -U it will update only if it wasn't configured not to do so. If it doesn't update, it tells you to use your package manager for example.

[rubenwardy]

Another victim of the outdated Ubuntu software store: https://forum.minetest.net/viewtopic.php?f=3&t=13807

[Calinou]

Another victim of the outdated Ubuntu software store: https://forum.minetest.net/viewtopic.php?f=3&t=13807

Debian (and Ubuntu, Linux Mint, …) strip out update checks/notifications anyway (since users are expected to upgrade their versions through the package manager). Adding an in-engine update check would be useful only for people who install from a PPA, or from source.

[rubenwardy]

Really?

[rubenwardy]

They strip out updating checking, but then never actually allow updates in their store?

[apoleon]

Am 28.12.2015 um 22:32 schrieb rubenwardy:

Another victim of the outdated Ubuntu software store:
https://forum.minetest.net/viewtopic.php?f=3&t=13807

First of all Ubuntu and Linux Mint are Debian derivatives.

https://wiki.debian.org/Derivatives

They share a common platform but differ in various ways. The latest
Ubuntu release, 15.10, ships Minetest 0.4.13.

https://launchpad.net/ubuntu/+source/minetest

Please encourage people to upgrade their systems instead or to ask for
help and support on dedicated Linux distribution forums like

http://ubuntuforums.org/

http://forums.debian.net/

or direct them to related official IRC support channels and other Linux
documentation.

Debian based systems provide an excellent package manager called "apt"
that installs, removes and upgrades software packages which are well
integrated into the user's system. There is simply no need for software
specific update notifications.

In this case the user runs Ubuntu 14.04 the LTS (Long Term Support)
version. That means it receives security updates for five years. He has
basically four options:

1. Upgrade to Ubuntu 15.10
2. Wait until April 2016 and upgrade to the next LTS version Ubuntu 16.04.
3. Ask the Ubuntu community or the Minetest developers to provide an
   official backport for Ubuntu 14.04 based on Ubuntu's latest version of
   Minetest.

https://help.ubuntu.com/community/UbuntuBackports

1. Recompiling the game himself by installing Ubuntu's Minetest source
   package from 15.04:
   • sudo apt-get build-dep minetest
   • sudo apt-get install build-essential
   • dget -x
     https://launchpad.net/ubuntu/+archive/primary/+files/minetest_0.4.13%2Brepack-1.dsc
   • cd minetest-*
   • debuild -us -uc

Then he can install the packages with

sudo dpkg -i *.deb

P.S.: Debian ships Minetest 0.4.10 in Debian stable but also provides a
backport of 0.4.13. Something similar should be done for Ubuntu.

[rubenwardy]

Please don't talk to me like that. It's rude and patronising. I am well aware of the distinction of aptitude, derbian and ubuntu

Minetest should be independent from OS versions.
The failure of this, of apt not finding the right version, is completely silent. The user thinks they have the most up to date version until they report a bug and we tell them.

The only good solution you gave is updating the version in the repos.

Launchpad is not our code repository. We are not defined by launchpad, that's just a deployment method.
If you want to build it yourself, you should use https://github.com/minetest/minetest/tree/stable-0.4

[nerzhul]

@rubenwardy another option is to host ourselves repositories for up-to-date minetest. Could be better.
my epixel fork has a jenkins task to package epixel into .deb and i'm working on a .rpm

[est31]

Well in fact there is launchpad nightly ppa, it auto-builds every night, for all supported ubuntu releases.

[sfan5]

Support for forks. A solution would need to have the ability to be disabled via minetest.conf.

No need for minetest.conf, forks can just remove the code.

[0-afflatus]

It's a good general idea with limited usefulness, mostly because most players probably don't understand versioning systems beyond a "must-have" label. It is unlikely to curb bug reports from people using older versions, because they won't understand (and neither do Debian really) that Minetest doesn't have the resources to maintain a separate 'stable' version and distributors don't have the resources to keep up with dev versions, in fact in most cases this would be bad practice. Generally developers need to be a bit (maybe a lot) more patient with end-users and accept that most of them have no idea about the development cycle. This means being patient and boringly closing many bug reports with "we believe the issue you raised is fixed in the latest version" or whatever. If you are a Debian user you tend trust the repository version, because otherwise you lose support from Debian, so it's possibly counter-productive to notify the user that they're using an outdated version. As the Debian testing/sid version is out of sync with Irrlicht and buggy it currently needs rebuilding anyway <- @apoleon .

[tobyplowy]

@rubenwardy +1

[NovaAndrom3da]

Might be good to include an update button with the notice, that will download it from github (if it was prebuilt) or pull changes & compile it from source (if the user compiled it). Just my $0.02 😄

[rubenwardy]

We need to start producing Windows installers, that's the best way to make it easy to update on Windows

[NovaAndrom3da]

Could it not just download the prebuilt zip containing the binaries?