While snap automatically updates when a new version is available. There is an option in snap to track branches that could be used to specify major tryton versions.
I guess it is something like pinning on Debian, but I think this will be quiet complicate for the average user and we will have less control on it than our current notification.
While I understand that the point is to have a extra unix button on the download page I am not sure introducing a new binary format for them is worth it.
Shouldn’t we just mention to our linux/bsd users that they should use whatever packaging system their OS use to install Tryton if available? It seems like this is the best practice anyway and if they want to have a more complicated setup then it’s up to them anyway.
For me, there are some issues with distribution packages. Tryton is not packaged in all distributions and the current trend is to have less distribution. In (almost) all distribution packages, the user can only install one version of the client. This can be a problem for users having to connect to different versions or if the update is not synchronized between the server and all the client OS. Also the change of series in the distribution package is not managed/scheduled by the company using Tryton.
So their only solution is to repackage Tryton to follow their own agenda. I think Tryton will help the deployment by providing binaries for each series.
I would be interested by knowing distributions that permit installation of several differents clients version (and how it is done).
The problem for packaging is that all tryton clients uses the same namespace at module level (tryton). So as currently distributed, the different versions are incompatible. it is additional work for distribution to provide a not standard installation that let them work together.
If the project provide a setup.py script that install python modules in separate modules (tryton50, tryton51, …) and I think no distributions will complain and all of them will have the possibility to install multiple versions of tryton desktop client.
I don’t think the idea is to install many versions at the same time but to choose which version to install, as the tryton server might have a different version than the one available in the distro repositories.
I agree that giving the user the flexibility to choose which version to install is important.
Indeed it is similar to Debian pinning.
I do like the self updating way snap works, though and how it reduces the end-user’s responsability on keeping the client updated.
Is the average user responsible for installing their own client? I’d expect that they are instructed or that software are installed in the computer by someone else than the average user. If that is the case, using a self updating client would reduce the effort of that person and the extra worry for the end-user to keep their client updated.
I don’t think this is a problem for the end user.
The company will have one production server on which people will connect using only one version of Tryton.
But this is an issue for people that are implementing Tryton in their organisation. Usually we can expect them to be able to manage different virtual environments but few might not be able to do so. The question is this worth the effort of supporting another binary distribution?
You pointed to pinning as a way to circumvent that issue. But I agree that when a distribution skip a package (like debian did some time ago) or when the maintainer stops there is an issue.
It is difficult to answer because we do not know the cost of it because we do not know which format yet.
Also the cost of the other binary is very low now because we rely on distribution like msys2 and bottle.
As far as I see, AppImage is quite similar to Docker in the sense that you start from a “distribution” and install your application in it. (I guess the others are similar). So for me, the main cost will be the initial setup. The maintenance cost will be very low.
For me installing the Flatpack on Linux Mint 20.3 Una worked without issue, although I was prompted to accept installing perhaps 6 gnome packages (sorry, did not grab screenshot showing exactly which packages), which I do not understand as I have no issues running the 6.6 client from source.
Also, fwiw, I expected the “Make sure to follow the setup guide before installing” link under the "Install button on the Flathub page would refer to a Tryton setup guide (not to a OS-specific Flatpak install page).
The installation process was certainly simpler than downloading and extracting the client source as I have done previously, and it was very nice to have a Tryton menu item automatically created in the Office category - including the Tryton logo! Imho having to run the client from source is asking too much of a “user”, and with the Flatpak a user can support themselves.
It will be interesting to see the client upgrade workflow when I upgrade the server next time. Personally, it would be nice if installing the new Flatpak replaced the old Flatpak (and even nicer if trying to access a newer edition server prompted me with a link to upgrade the Flatpak).
All in all, the Flatpak was a nice experience and I’ll happily delete the 6.6 source copy.
Dale
P.S. I had voted for an AppImage version based on Nextcloud using AppImage for their desktop client, but now I think the Flatpak is better for non-technical users and will change my vote.
This is the standard generate page of flathub and it can not be customized.
This should be transparent for the the same series by using flatpak update.
But for new series, it will be required to install a new flatpak package with the proper suffix.
I do not think we will introduce specific flatpak code in the client/server for this case.
I had expected not, but thought worth mentioning anyway.
The Flatpak solves a problem on another Linux Mint latop that’s apparently missing the Python dateutil module (running the Tryton client from source throws an error). The. Flatpak runs without issue.