jamulus Version check for disconnected environments

EDIT: For current status, see https://github.com/jamulussoftware/jamulus/issues/1178#issuecomment-919784342

Has this feature been discussed and generally agreed?

Improving version checks has been previously discussed in #1120. As part of that issue reliability has been improved by checking two independent public servers.

This leaves the following unsolved:

Disconnected environments with no Internet access can still not get update notifications.
Should we ever have problems with the jamulus.io domain, we'd currently not have a way to signal updates.

Describe the solution you'd like This issue is about deciding (and implementing) if we further want to extend this to checking the currently connected (possibly private) server.

Describe alternatives that have been considered

The alternative is not implementing it.

@jamulussoftware/maindevelopers Can you comment or add a reaction if this should be done? (My impression was that @softins did not consider it necessary while @pljones was in favor?)

Mar 05 '21 17:03 hoffie

Yep - I think adding as part of the connect cycle would have low impact and increase usability. In a semi-closed environment, one (custom directory) server could be upgraded and that would trigger all client users of the need to upgrade.

(It's also partly why I'm against embedding the download link in the software - in such an environment, it's meaningless.)

Mar 05 '21 17:03 pljones

In general, I'd support this idea. What would happen the server you connect to runs a newer (beta) release or custom version? Would it (falsefully) show the message?

Mar 05 '21 20:03 ann0see

What would happen the server you connect to runs a newer (beta) release or custom version? Would it (falsefully) show the message?

For intermediate versions (any suffix after the version number), the update check is skipped (as implemented by @softins in #1155), so we should be safe.

If someone chooses to build their own Jamulus versions which do not use suffixes and has higher version numbers than we have, they will be out of luck and will have to find their own way. They'd probably have the knowledge do that anyway. :)

Mar 05 '21 21:03 hoffie

For intermediate versions (any suffix after the version number), the update check is skipped

That's good.

If someone chooses to build their own Jamulus versions which do not use suffixes and has higher version numbers than we have, they will be out of luck and will have to find their own way.

Not really happy about this solution then. Probably an overkill but we could introduce logging and once the client knows that multiple different servers are running a higher version, we could fire this message. Another (quick) way would be a slightly different message in another colour telling the user that the server is running a newer version than the client. Users would probably (hopefully) conclude that an update might but doesn't have to be available.

Mar 05 '21 21:03 ann0see

but we could introduce logging and once the client knows that multiple different servers are running a higher version, we could fire this message.

Hrm, I think this would reduce the usefullness. I'm mainly thinking of people who connect to just a single server.

Another (quick) way would be a slightly different message in another colour telling the user that the server is running a newer version than the client. Users would probably (hopefully) conclude that an update might but doesn't have to be available.

I'd be open to that, yeah. What's your concern though? That unknowing users connect to a server which claims to run Jamulus 5.0.0 or something?

Mar 05 '21 22:03 hoffie

That unknowing users connect to a server which claims to run Jamulus 5.0.0 or something?

Yes. Although I doubt this happens often, it's not impossible and should therefore also be handled correctly.

Mar 06 '21 08:03 ann0see

Yes. Although I doubt this happens often, it's not impossible and should therefore also be handled correctly.

I think the most realistical thing to implement would be to adjust the message in this case as you proposed.

E.g. "The server you are currently connected to is running a newer Jamulus version than you. You might want to check for available updates." (which sounds long, maybe someone can shorten it).

Mar 06 '21 08:03 hoffie

@hoffie What's the reason why we'd not just say what we say today? I don't think we need to explain how we're doing the check - or am I misunderstanding? (and "You might want to check for available updates" is ambiguous - it might mean check for updates on the client or the server. And it assumes the user knows the difference).

Mar 08 '21 20:03 gilgongo

Also META COMMENT: Interesting use of "waiting on team" to hide the fact that this is really a discussion not an issue! Ah, project management ... :-)

Mar 08 '21 20:03 gilgongo

What's the reason why we'd not just say what we say today?

Today, we only check servers which we control. Therefore, we know that they run official Jamulus releases and can therefore be very explicit in the message. @ann0see's argument was that people running modified Jamulus editions (with other versioning) will lead to unexpected update notifications that could irritate users. If we want to handle that case, the only low-complexity fix I see would be updating the message to say what we actually check (maybe only in this case though).

You might want to check for available updates" is ambiguous - it might mean check for updates on the client or the server. And it assumes the user knows the difference

Yes, you're right. If we implement it, we should clarify that.

Interesting use of "waiting on team" to hide the fact that this is really a discussion not an issue!

Yes, it starts becoming a discussion the more we think about implementation and possibly edge cases. I'd still say that this is a specific problem to be solved, benefits from being tracked in the project and should be tracked as an issue. :)

Mar 08 '21 21:03 hoffie

people running modified Jamulus editions

So the current message might (but not always) result in them going "Huh? But I am running the latest version" or needlessly reinstalling? But if the version check will be annoying to a significant number of people, then I think we have a case of bad design :-) If (as I hope!) a false positive only happens occasionally, then I'd just keep the standard wording in (which is clear and people are used to seeing such messages) but put a tooltip or info icon next to it saying maybe, "Note that if the server is running a non-standard version of Jamulus, you may already have the latest version and don't need to upgrade." The "80/20 rule": don't confuse the majority for the sake of the minority.

benefits from being tracked in the project and should be tracked as an issue

Yes, sorry I didn't mean it as a criticism. It is after all for the team to feed back on. I just didn't consider the use of "waiting" state properly :-) Still finding our way with all this...!

Mar 09 '21 07:03 gilgongo

Sorry for the stupid question - but why can't we use the version that's on GitHub?

Mar 14 '21 20:03 gilgongo

but why can't we use the version that's on GitHub?

I had never thought about it. I think we could. This would involve moving the (or adding a) check from a Jamulus-protocol-based one to a HTTP-based one. Qt does include QHttp, so this seems to be doable. This could be an option if we wanted to have a jamulus.io-independent way. It would still not work for disconnected networks.

Mar 14 '21 20:03 hoffie

Just found this related issue: https://github.com/jamulussoftware/jamulus/issues/370

Mar 14 '21 22:03 hoffie

Yes I was having deja vue on this issue...

It would still not work for disconnected networks

Been meaning to ask - what is a "disconnected network" in this context? One that can't see GitHub? Do they exist?

Mar 15 '21 08:03 gilgongo

Many organisations will have a restrictive firewall. It may only allow internal systems access to external port 80 and 443 and further filter those by domain. They'll be running Jamulus entirely internally - maybe just the one server, maybe an internal directory and multiple servers - but the clients aren't expected to connect to the internet, just that internal network.

Essentially, that network is disconnected from the internet.

Mar 15 '21 08:03 pljones

but why can't we use the version that's on GitHub?

I had never thought about it. I think we could. This would involve moving the (or adding a) check from a Jamulus-protocol-based one to a HTTP-based one. Qt does include QHttp, so this seems to be doable.

Just need to fetch https://api.github.com/repos/jamulussoftware/jamulus/releases/latest and then check the name property. Would need to translate between r3_7_0 and 3.7.0

This could be an option if we wanted to have a jamulus.io-independent way. It would still not work for disconnected networks.

So long as the check is in a non-blocking thread and gives up, that's fine.

Mar 15 '21 12:03 softins

Many organisations will have a restrictive firewall.

It isn't worth the trouble trying to solve this problem. We just need a mechanism to remind the user their installation is isolated. Maybe "it has been more than xxx days since checking for a new release" or whatever message we think is warranted. This is especially important to the clients. But if ALL the clients and the server is in a bubble behind the firewall, then they operate as a time-capsule.

Mar 15 '21 17:03 gene96817

Just need to fetch https://api.github.com/repos/jamulussoftware/jamulus/releases/latest and then check the name property. Would need to translate between r3_7_0 and 3.7.0

See https://github.com/jamulussoftware/jamulus/issues/370#issuecomment-653859296 :)

Mar 15 '21 18:03 pljones

If we're worried about catering for people who block GitHub (and I'd block it if I could), then how about falling back to the server after a timeout? That way, we can have the proposed "... according to the server version" message that would otherwise be confusing.

Mar 15 '21 18:03 gilgongo

But if ALL the clients and the server is in a bubble behind the firewall, then they operate as a time-capsule.

I guess anyone who's in such a restrictive environment they can only use updates managed through OS/distribution-specified services (Apple Store, Windows Update, yum / apt / etc distribution management) or through locally provided services, as we're not supplying directly through those channels we can expect them to use the compile flag and build their own versions for installation. And then they choose when to update by building and installing (through their own installation processes) a new version.

Mar 15 '21 19:03 pljones

Taking a step toward being helpful, the client can report something like "This server hasn't check for updates for over xxx days." where the reminder starts after 100 days.

Mar 16 '21 05:03 gene96817

Update notification now included in 3.8.1.

Sep 14 '21 07:09 gilgongo

I think this issue is about something else:

This issue is about deciding (and implementing) if we further want to extend this to checking the currently connected (possibly private) server.

Sep 14 '21 07:09 ann0see

Oh the screenshot on #1980 of the server GUI confused me, my mistake.

This issue is 6 months old, but I'll re-open.

Sep 14 '21 21:09 gilgongo

This issue is 6 months old, but I'll re-open.

It only became an issue with 3.7.0 and we've only had one version released since then. So that's hardly much development time to get it addressed. It's not high enough priority...

I think @hoffie's summary still makes it clear what needs addressing:

Disconnected environments with no Internet access can still not get update notifications.
Should we ever have problems with the jamulus.io domain, we'd currently not have a way to signal updates.

Both of these need not to direct the user to the jamulus.io website for further information. Indeed, in both cases, jamulus.io might not be accessible (the first because of firewalls, the second because it doesn't exist).

So something like:

check the two update servers for a newer version - any response from them is definitive and should be alerted as now (3.8.1)
if running a client and accessing a directory server, check its version otherwise check the current server version, or if running a registered server, check the directory server version; if it's newer, indicate a version update should be made (without saying how)
if running a standalone server, you're on your own...

Hopefully, for the second scenario, there would still be other methods of communication open - like Github, Facebook and Sourceforge - that could be used until the built-in system could be fixed.

Sep 15 '21 07:09 pljones