Notify user about new client version

Rational

When using pre-build client, a user does not know if there are a new build available.
So user should be notified when a new release is available.
The notification should not be too intrusive to not disturb the user to work and should not be too frequent neither.

Proposal

A new notification option will be available from the menu, it will be active by default.
If the option is activated, randomly the client will send a HEAD request to the URL to download the next version depending of the OS:

  • Windows: https://downloads.tryton.org/<series>/tryton-setup-<version>.exe
  • Mac: https://downloads.tryton.org/<series>/tryton-<version>.dmg
  • Other: https://downloads.tryton.org/<series>/tryton-<version>.tar.gz

The rate of the request should be low and random to not overload the Tryton servers. I think once a week is a good average.
Those requests will be launch by a thread which will trigger a InfoBar with the link of the new version to download.
There will be a loop to check the next bug-fix release and if it is found, we keep checking the next one to find the latest.

Implementation

https://bugs.tryton.org/issue7033

2 Likes

We should allow to activate or deactivate the autoupdates after the first run.

I would not go for autoupdate at all, just for notification.
If you installed from distribution packages, the update will be offered anyway


+1. Only for notification

First of all I agree it should be neither autoupdate nor autodownload, but only notification.

Some more thoughts from the point of view of distributions:

  • Avoid the first question (if ‘autoupdate’ should be activated):
    Usually you don’t want such a question, because the distribution handles the updates on its own (i.e. this question will lead unexperienced users of distribution packages to do exactly the wrong thing: they will interfere unintentionally with the package manager of the distribution).

  • Since this is some sort of Phoning Home feature, it should disabled by default and it should be activated by the user himself.

    • The best option is to make the autonotification feature just a configurable client option. From the distribution point of view it should be possible to hide the menu entry itself.
    • If nevertheless questions shall be asked to the user, it must be possible to disable this feature either at build time (preferred) or read from sytem wide configuration (e.g. /etc/ tryton like /etc/trytond.conf). Otherwise distributions will have to patch out the feature.

Since the rationale is the notfication for users of pre-built clients it would be best to enable it only for Windows and Macs.

When enabled the client could just do the request on startup instead of doing random requests, which will also be better in terms of security, if there should be a security release.

Since I was initiating this discussion at TUL: after reading your posts I think there are to many reasonable concerns and to less benefits. I had this problems with customers on windows . So I should manage notification of updates by my own by monitoring the last build date of setup.exe

I think really benefits is not only notification, is get update, the problem is how?

So for example in the Help menu add option “Update a new version X.X.X” and it ask to the user “Are you sure you want update?”, and start process, this is very useful when you have +100 users, update on this way is easier than go to the tryton.org / downloads 
 (where profile between versions ever missing)

The proposal do not talk about auto-update.

Indeed, I think it is more user-friendly to activate it by default. Only experienced users will want to deactivate it.

Indeed I think for non frozen setup, we should only notify but not provide download link.

I do not think it is a good pattern because:

  • It could generate a lot of requests in short time if the client is restarted multiple times.
  • We could have large setup that starts the client automatically and in case of global restart, this could flood the server
  • Client could be kept running for a very long time without being restarted.

As explained in the proposal: by providing a download link.

As I already said, it is not distribution-friendly. And the people using distributions are users, right? So the activation by default is at least partly not user-friendly.

The main question is: Will it be possible to disable this feature easily at build time or start time?

What do you mean by “frozen setup”?

  • The number of requests when restarting clients multiple times should be negligible compared to the load this feature will cause altogether. But it should for sure be sufficient to ask once a day.
  • Large setups not managing the distribution of the client by themselves should be very uncommon. But anyway: if the server can not handle this number of requests you shouldn’t provide the feature.

I would really solicit to take the input of this discussion seriously and take the time to answer and finalize it instead of just acting.

  • The change you plan to introduce is mostly a tribute to few (non-free) distributions. Usually the maintainers of distributions are supposed to provide and use the standard tools of the distribution to keep their userland updated. If a distribution doesn’t provide the tools it is the deficit of this very distribution. Is it really a wise decision to put the burden of those missing tools onto other distributions which are able to take care?
  • That said the only gain currently is the advertisement of a bug fix release for a mostly uncritical component of the system. There are much more critical components.
    • Hint: Please compare the number of security issues for the gtk client and the server.
  • There is a guideline that both clients (gtk and web) should be kept synchronized. Where are those changes for sao which due its nature should be a real and substantial target for important vulnerabilities? (I think it is correct to assume that quite a big number of sao installations are running unmonitored for the security impacts of their javascript dependencies
)

Thus this feature introduces more impact than usefulness.

  • First this feature should be a build option only for the said binary distributions (or better: not be part of the base package at all).
  • When enabled it should not be activated by default, interfering with the management tools of downstreams.
  • Furthermore it should not appear as prominent in the menu, but under settings for experienced users.

The proposal as it is will conflict with many downstreams. It will have to be patched out when speaking for Debian and I think for quite some other downstreams (pretty each binary linux distribution, gnuhealth, 
).

Thanks for considering.

It introduce not burden.

sao is not managed by end users.

Other users need to be warned also.

It does not interfere with anything as it is just a notification.

I do not see the rational to let only to experienced users the choice. Non-experienced users should have the right to choose also.

Those managing their own userlands can build client versions with the default off, or the function disabled. It is maybe a new skill for them to learn, but won’t be challenging after initially figuring it out.

This topic was automatically closed after 20 days. New replies are no longer allowed.