Check For Updates

[corrados]

Copy from https://sourceforge.net/p/llcon/discussion/developerforum/thread/506419bd89

Please add a Check For Updates function (menu item) to the Client and Server (GUI). It could be done in phases:

1. Query Github to see if there is a newer version than what is running, and informs the user, perhaps with a hyperlink to the newest version.
2. If there is a newer version, offer to download it.
3. After downloading, automatically install.
4. Provide an "always update on startup" option.

[pljones]

I've had something similar in a few applications I've written.

• Publishing the new application release created a file "latest.txt" or similar in a known location.
• The user could manually request this or set an option to do it each time the application ran (at most once a day).
• The application would download the "latest.txt", which contained:
  • the latest version number
  • the URL to go to
  • a description

The version number would be compared with the running application version number and, where newer, the user offered the option to go to the URL, also displaying the description text.

I actually implemented it twice, once in C# and once in Scala.

The Scala version is here:
https://github.com/pljones/jTrapKATEditor/blob/master/src/main/scala/info/drealm/scala/updateTool/Checker.scala

The slightly more cumbersome-looking C# one is in several places, of which this is one:
https://sourceforge.net/p/sims3tools/git/ci/master/tree/s3pe/Settings/AutoUpdate.cs

[corrados]

The Jamulus software contacts some server and queries some information. Then it maybe downloads a file and executes it. I can see multiple ways for a hacker to use this to modify informations and inject unwanted code. Before anything is implemented, we should discuss possible security issues here: #314

[WolfganP]

It's interesting to have the program check for updates. Probably a good start will be to just check and notify, and let the user take action (ie just implement your 1st step aboce)

[pljones]

I don't like "automatically run" but a lot of users seem to want this from software to make their life a one click solution...

[gilgongo]

It's speculation of course, but an update notification might prompt some server operators to upgrade to make use of genre-based Central Servers. This might further reduce the numbers on the defaults as there are a lot of pre-3.5.4 servers running. But it's perhaps a minor point :-)

[pljones]

They'd have to upgrade to get support for the notification.

[gilgongo]

Initially, yes (hence my "minor point"). I was thinking further ahead if update notifications mean that server operators don't simply stick with the version they first downloaded, as currently seems to be the case for many. Out of sight, out of mind, as it were.

[pljones]

If they were running the server as a service, even if it notified once a day (rather than only on start up), they operator would still need to check the logs. Most of the time the server really is out of mind, as it just works.

To get any attention - and it wouldn't be a very nice approach - you could update the server welcome message to indicate it's out of date. Everyone entering the server would then see it. Hopefully the server operator would eventually spot it...

[gilgongo]

Yes, not easy. I guess perhaps the only realistic route to encouraging upgrading to a given version is if a change (or security issue?) was introduced to prevent old servers from connecting to new central servers perhaps.

But I guess there isn't much reason to encourage people to upgrade servers really. It might benefit other server operators by freeing up more slots on the two former geo-based central servers perhaps, and of course help clients who wanted -F.

[gvermag22]

It's somewhat unfair that JamulusOS has an update Jamulus ability, but Mac and windows don't. Moreover, one must go through multiple steps to update Jamulus on Mac, which is not such a good experience. We realize that Jamulus is evolving, and it would be better for users to know the latest features by trying them out in an easier manner. There should also be an easy/intuitive way for people to review the release notes for a specific release version. e.g. I have no idea what are the new features/enhancement in version 3.5.8

[pljones]

It's somewhat unfair that JamulusOS has an update Jamulus ability, but Mac and windows don't.

Someone put the effort in to make it happen. It's not a matter of "fairness". The Linux build itself doesn't, it's just like the Windows one and the MacOS one.

JamulusOS is an entire Linux Distribution, like CentOS or Ubuntu, not just the Jamulus software. So, just like Windows will update itself, JamulusOS (the operating system) will update itself.

So really, a "like for like" complaint would be "There's no version of Windows with Jamulus built in and maintained by the Microsoft OS maintenance team" or the equivalent for MacOS.

[gvermag22]

JamulusOS was an excellent idea, and we are thankful for the great development work.

…

On Sat, Jul 4, 2020 at 10:00 AM Peter L Jones ***@***.***> wrote: It's somewhat unfair that JamulusOS has an update Jamulus ability, but Mac and windows don't. Someone put the effort in to make it happen. It's not a matter of "fairness". The Linux build itself doesn't. JamulusOS is an entire Linux Distribution, like CentOS or Ubuntu, not just the Jamulus software. So, just like Windows will update itself, JamulusOS (the operating system) will update itself. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#370 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQCIRBPSKUWF4MUSCL75PETRZ5N2PANCNFSM4OAZVQKA> .

[pljones]

Actually, I take part of that back.

I'd have been better saying "Why don't Microsoft and Apple make a standard distribution mechanism for add on apps?" And I guess they do - they both have app stores. So, just like many of the Open Source Linux Distributions have people contributing Jamulus builds to them, enabling users of those distributions to get automatic updates, it may be possible for someone to publish builds to Microsoft and Apple stores. Never having used either store, I wouldn't know.

[gilgongo]

I would guess they'd need to pay for the privilege :-)

[gilgongo]

BTW @pljones

Publishing the new application release created a file "latest.txt" or similar in a known location

I see that https://api.github.com/repos/corrados/jamulus/releases/latest does this (as long as Volker remembers to hit the "publish" button on the release)

[pljones]

Which lets the user check the version nicely, yes. I'd still suggest sending them to https://sf.net/projects/llcon for the download as that response doesn't indicate a platform-specific installer, which is what most users would want.

Although I wonder if "assets": [], could be filled in with the details (even if hosted on sf.net).

[gilgongo]

Yes the FS download link is the mot efficient, supplemented by the link to the changelog perhaps (although that might confuse some people as usually has the git head release in it).

I wonder if servers could then have a command line option to provide an email address for update notifications?

[pljones]

I wonder if servers could then have a command line option to provide an email address for update notifications?

Like I've been muttering everywhere, everything that's available through the UI should be available through command line and vice versa. So yes, some way of getting notifications for updates if you're running without the UI would be good.

[gvermag22]

I was hoping there could be a check for updates menu item that would easily allow us to upgrade the server and client versions for Mac or windows. Other programs do that.

…

On Sun, Jul 5, 2020 at 1:46 AM Jonathan ***@***.***> wrote: BTW @pljones <https://github.com/pljones> Publishing the new application release created a file "latest.txt" or similar in a known location I see that https://api.github.com/repos/corrados/jamulus/releases/latest does this (as long as Volker remembers to hit the "publish" button on the release) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#370 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQCIRBPNFP3RFOBPEVU3J73R2A4UTANCNFSM4OAZVQKA> .

[pljones]

@gvermag22, that's what we're discussing here.

[pljones]

@gilgongo,

The problem with sending an email is ... you need to become an email client and know how to contact a server. A Raspberry Pi may be set up for Jamulus and nothing else, so even if you open port 23 and dump the email in, it doesn't mean it's going to (a) work (maybe nothing is listening) or (b) get delivered (maybe SMTP service is running unconfigured). And I've no idea about, say, a Windows Cloud VM server...

And at-me... what I was saying earlier about the Welcome message -- I've no idea what I was on about...

So we have:

Client (assume UI showing on all platforms):

• Can't do anything about old versions already out there
• New feature offers "Check for updates now" and displays the response
• New feature offers "Automatically check for updates once a day", which checks on start up if it hasn't in the last 24 hours and displays the response only if there's a new version
• Details are requested from https://api.github.com/repos/corrados/jamulus/releases/latest
• If the local version is out of date, the ChangeLog is also requested
• The response shows the current version, the latest version plus the relevant parts of the ChangeLog (in a "Details" box)
• The response also shows the SourceForge link to download the latest version, if possible allowing the link to be clicked and opened in the user's default web browser
• The response is shown on a focussed centred alert dialog box (at Info level of importance)
  
  but with more info about the change than I did there.

Server - UI showing

• Works as per client

Server - built headless or running without the UI

• Checking for new versions should not be enabled by default (because we don't know the local network set up)
• Only if enabled are the following steps taken
• Details are requested from https://api.github.com/repos/corrados/jamulus/releases/latest
• If the local version is out of date, the ChangeLog is also requested
• Details of the current version, the latest version plus the relevant parts of the ChangeLog are written to "standard out"
  • This should be at a higher priority than a standard "Info" message (apart from the ChangeLog details)
  • This should end up in the "system log"
  • Ideally this would end up in the Windows Event Log or similar -- I'm not sure where is "normal" for servers

[pljones]

I'm thinking I might give the client end of this a go, next.

[gvermag22]

THank you, that would be great!

…

On Tue, Aug 18, 2020 at 4:35 AM Peter L Jones ***@***.***> wrote: I'm thinking I might give the client end of this a go, next. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#370 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQCIRBOCQI2GVQ3DUDNVJILSBJRRTANCNFSM4OAZVQKA> .

[pljones]

#554 is the first commit for this.

There's possibly a few more things that could be done - specifically for the server to have a timed checker so it polls once a day. As it is, the checker only runs on start up or request from the UI.

[corrados]

Thanks for your code. Unfortunately, I have not read your specification prior to your coding correctly.

Server - built headless or running without the UI

• Details of the current version, the latest version plus the relevant parts of the ChangeLog are written to "standard out"
• This should end up in the "system log"

I actually do not want this functionality for headless mode at all. GUI only support is what I want. You have changed that the headless server mode now always uses the settings file as given in the home directory. I actually do not want this. For the headless server mode I want so specify the behaviour on the command line. So everything works as expected and no unknowns on startup. So if you want to use an ini-file in headless server mode, you have to specify it with --inifile. That is predictable behaviour.

As in your specification, the version check output goes on standard out and system log. I do not think that Jamulus server operators expect the headless Jamulus making version checks at all. I do not think they will check the standard out or system log. I think the version check should be supported in the Jamulus client and server GUI. When the GUI is started, the check is performed. That is enough.

Sorry for starting the discussion on that a bit too late.

[gilgongo]

So if you want to use an ini-file in headless server mode, you have to specify it with --inifile.

Off topic question, but I assume the current behaviour is that the client will create and always use an inifile, while the server will not unless you use --inifile in which case (some?) things on the command line at startup will be overridden? The feels like it needs some more documentation if so.

(For what it's worth - I agree that most server operators probably won't check logs and std out. I know I don't! This is a pity as it would be nice to have all those out of date servers upgraded. Would it help if the server version was displayed in the client together with an "upgrade available" message perhaps? Not sure if that was discussed.)

[corrados]

while the server will not unless you use --inifile

No, if the server is run in GUI mode, it will use the default ini file automatically like the client does. Just the headless server which is started on the command line will not use it per default but only if you explicitely specify it with --inifile.

[corrados]

I just coded a few lines and it works like a charm.

[gilgongo]

Incidentally, there is of course a possible confusion in the case of the client GUI (assuming I understand correctly your interpretation of the idea): will people think the upgrade message refers to their own client as opposed to the server they are connected to? If so, it may be hard to know how to make that clear if people don't have a good understanding of the difference between clients and servers.

[corrados]

I would not write the version number as in your screen shot. The only information relevant to the Jamulus user is that there is a newer version available. So just show a text "Jamulus software upgrade available".

[gilgongo]

Ah ok so in the case of the client UI it's a client version check. I was thinking we'd show a server version check there in an attempt to get headless servers upgraded by their owners (assuming server owners connect to their own servers with up to date clients). But I guess that is possibly a bit strange.

[corrados]

The update checker queries the Default Central Server version number. This is under my control. So as soon as a new Jamulus version is out, I'll upgrade the Default Central Server.

[pljones]

Sounds a great solution.

I wasn't really happy with the weight of code I was having to add to get something so simple into the code: I'd expected it to be "get this JSON blob from here, parse it, get this chunk from here, parse it, display"... but every network retrieve and parse exploded... I'm getting lazy working with Java and SpringBoot.

[corrados]

Very good that you also like the new specification. Here is the result:

I have put version 3.5.9 in the Jamulus.pro file to force the label to be shown in this screen shot.

[storeilly]

I think the message needs to specify client or server version info and which needs upgrading. This message is confusing, users will only upgrade their own clients then complain the message is wrong. It won't push server operators to do anything.

…

On Sun 30 Aug 2020 at 10:36, Volker Fischer ***@***.***> wrote: Very good that you also like the new specification. Here is the result: [image: grafik] <https://user-images.githubusercontent.com/46655886/91655948-ed08a100-eab4-11ea-98a3-761474bf2c84.png> I have put version 3.5.9 in the Jamulus.pro file to force the label to be shown. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#370 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABIJSQPMUXNMKIP5CIBFHDLSDIMRRANCNFSM4OAZVQKA> .

[corrados]

It won't push server operators to do anything.

The "upgrade available" info only refers to the client in that screen shot. The Jamulus server GUI will get something similar, soon. So if you start the Jamulus server GUI and your version is outdated, you will see this label in your server GUI.

[gilgongo]

Cool. I do wonder about all those very old server versions out there. But I understand if that proves to be an issue we can prevent them from registering with central servers if need be.

[corrados]

Here it is for the server GUI, too:

[corrados]

I set this Issue to done now. We can still continue the discussion on this matter and if we decide there is more to do, we can re-open the Issue again.

[lgbaldoni]

I maintain the Jamulus package on openSUSE and this feature could be misleading for the users installing it via the distribution.

Short of reverting all the commints mentioned in this thread, what's the easiest way to disable the update mechanism?

[pljones]

@corrados, given there's a number of situations where automatically checking for updates could be problematic - many large organisations won't want it, for example, especially if Jamulus is only meant to access an internal network - I'd suggest making it an option (Help->Update Checking or similar).

[lgbaldoni]

@pljones, a build option would be ideal. But I realise it'd be some work and only a minority would benefit form it.

[pljones]

I nearly suggested a build option but I think it has wider value in a user retaining control.

[corrados]

Let's start with the compile flag. That is very simple to implement and this is what lgbaldoni prefers.

I'll take care of it now.

[gvermag22]

I'm sorry, but when I downloaded the latest release, I could not see this feature in the UI. But it was included per the release notes? What am I missing?

…

On Wed, Sep 23, 2020 at 8:37 AM Volker Fischer ***@***.***> wrote: Let's start with the compile flag. That is very simple to implement and this is what lgbaldoni prefers. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#370 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQCIRBN2ROJYM7RE7UYQLQDSHII3HANCNFSM4OAZVQKA> .

[gilgongo]

@gvermag22 It's a new feature in the current release. When the next release comes out, you will see message saying a new version is out :-)

[gvermag22]

Ohkay But I thought the whole point of this feature was to download and install from that window like other programs. On MacOS, whenever I install a new version, I have to go to settings each time and unblock it due to security reasons.

…

On Wed, Sep 23, 2020 at 10:05 AM Jonathan ***@***.***> wrote: @gvermag22 <https://github.com/gvermag22> It's a new feature in the current release. When the *next* release comes out, you will see message saying a new version is out :-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#370 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQCIRBN7LEVSO5CW7SXJGB3SHITERANCNFSM4OAZVQKA> .

[gilgongo]

It's simply a message in the UI. You still need to go an download and install the new version according to the platform you are running. Anything automatic is potential security issue so we won't be doing that, I'm afraid.

I have to go to settings each time and unblock itdue to security reasons.

That's a separate issue. Somebody has very kindly offered to pay for code signing I think, Not sure when/if that will happen though yet.

[corrados]

@lgbaldoni I just added the qmake CONFIG flag for disabling the version check for you: a05f354

[lgbaldoni]

@corrados thanks a lot!