.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](https://developer.gnome.org/gtk3/stable/GtkInfoBar.html) 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
> **[Option to check version (#7033) · Issues · Tryton / Tryton · GitLab](https://foss.heptapod.net/tryton/tryton/-/issues/7033)**
>
> From https://discuss.tryton.org/t/notify-user-about-new-client-version/460
---
### Author:  [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [December 12, 2017, 8:18am UTC](https://discuss.tryton.org/t/notify-user-about-new-client-version/460/2 "2017-12-12T08:18:37Z")
We should allow to activate or deactivate the autoupdates after the first run.
---
### Author:  [@coogor](https://discuss.tryton.org/u/coogor)
#### Post date: [December 16, 2017, 4:25pm UTC](https://discuss.tryton.org/t/notify-user-about-new-client-version/460/3 "2017-12-16T16:25:59Z")
I would not go for autoupdate at all, just for notification.
If you installed from distribution packages, the update will be offered anyway…
---
### Author:  [@resteve](https://discuss.tryton.org/u/resteve)
#### Post date: [December 16, 2017, 4:59pm UTC](https://discuss.tryton.org/t/notify-user-about-new-client-version/460/4 "2017-12-16T16:59:41Z")
+1. Only for notification
---
### Author:  [@yangoon](https://discuss.tryton.org/u/yangoon)
#### Post date: [December 18, 2017, 2:24pm UTC](https://discuss.tryton.org/t/notify-user-about-new-client-version/460/5 "2017-12-18T14:24:38Z")
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](https://en.wikipedia.org/wiki/Phoning_home) feature, it should disabled by default and it should be activated by the user himself.
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.
---
### Author:  [@jgras](https://discuss.tryton.org/u/jgras)
#### Post date: [December 19, 2017, 10:23am UTC](https://discuss.tryton.org/t/notify-user-about-new-client-version/460/6 "2017-12-19T10:23:57Z")
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
---
### Author:  [@oscar](https://discuss.tryton.org/u/oscar)
#### Post date: [December 21, 2017, 11:37pm UTC](https://discuss.tryton.org/t/notify-user-about-new-client-version/460/7 "2017-12-21T23:37:27Z")
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](http://tryton.org) / downloads … (where profile between versions ever missing)
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [December 23, 2017, 11:07am UTC](https://discuss.tryton.org/t/notify-user-about-new-client-version/460/8 "2017-12-23T11:07:46Z")
> [@pokoli](#):
>
> activate or deactivate the autoupdates
The proposal do not talk about auto-update.
> [@yangoon](#):
>
> Avoid the first question
Indeed, I think it is more user-friendly to activate it by default. Only experienced users will want to deactivate it.
> [@yangoon](#):
>
> Since the rationale is the notfication for users of pre-built clients it would be best to enable it only for Windows and Macs.
Indeed I think for non frozen setup, we should only notify but not provide download link.
> [@yangoon](#):
>
> 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.
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.
> [@oscar](#):
>
> I think really benefits is not only notification, is get update, the problem is how?
As explained in the proposal: by providing a download link.
---
### Author:  [@yangoon](https://discuss.tryton.org/u/yangoon)
#### Post date: [December 23, 2017, 12:15pm UTC](https://discuss.tryton.org/t/notify-user-about-new-client-version/460/9 "2017-12-23T12:15:45Z")
> [@ced](#):
>
> Avoid the first question
>
> Indeed, I think it is more user-friendly to activate it by default. Only experienced users will want to deactivate it.
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?
> [@ced](#):
>
> Indeed I think for non frozen setup, we should only notify but not provide download link.
What do you mean by “frozen setup”?
> [@ced](#):
>
> 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.
>
> 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.
- 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.
---
### Author:  [@yangoon](https://discuss.tryton.org/u/yangoon)
#### Post date: [January 1, 2018, 6:53pm UTC](https://discuss.tryton.org/t/notify-user-about-new-client-version/460/10 "2018-01-01T18:53:20Z")
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](https://codereview.tryton.org/40901002/).
- 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.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [January 2, 2018, 9:23am UTC](https://discuss.tryton.org/t/notify-user-about-new-client-version/460/11 "2018-01-02T09:23:26Z")
> [@yangoon](#):
>
> Is it really a wise decision to put the burden of those missing tools onto other distributions which are able to take care?
It introduce not burden.
> [@yangoon](#):
>
> Where are those changes for sao which due its nature should be a real and substantial target for important vulnerabilities?
sao is not managed by end users.
> [@yangoon](#):
>
> only for the said binary distributions (or better: not be part of the base package at all)
Other users need to be warned also.
> [@yangoon](#):
>
> interfering with the management tools of downstreams
It does not interfere with anything as it is just a notification.
> [@yangoon](#):
>
> Furthermore it should not appear as prominent in the menu, but under settings for experienced users.
I do not see the rational to let only to experienced users the choice. Non-experienced users should have the right to choose also.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [January 12, 2018, 2:52pm UTC](https://discuss.tryton.org/t/notify-user-about-new-client-version/460/13 "2018-01-12T14:52:21Z")
---
### Author:  [@jonl](https://discuss.tryton.org/u/jonl)
#### Post date: [January 25, 2018, 3:38pm UTC](https://discuss.tryton.org/t/notify-user-about-new-client-version/460/14 "2018-01-25T15:38:27Z")
> [@yangoon](#):
>
> 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.
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.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [February 1, 2018, 5:00pm UTC](https://discuss.tryton.org/t/notify-user-about-new-client-version/460/15 "2018-02-01T17:00:08Z")
This topic was automatically closed after 20 days. New replies are no longer allowed.