flatpak
Flatpak update should show version numbers
Linux distribution and version
Ubuntu 20.04
Flatpak version
Flatpak 1.6.3
Description of the problem
flatpak update does not show the version to upgrade to before asking for confirmation.
Steps to reproduce
Run flatpak update when updates are available.
Most of the time it won't have anything useful to say. Minor rebuilds happen all the time.
This is why it is even more important: With the version displayed, the user can identify when an actual new version is going to be installed or if it is just a rebuild!
Just because the version doesn't update doesn't mean its just a rebuild though. A flatpak is generally made up of many modules, and the version in the appdata only talks about the leaf module (the app). It could be updating some library that fixes important issues. So, versions are not as useful as you might think.
Still, wouldn't hurt.
Sometimes apps have important changes that I'm loooking for and I just want to update because of that version. Sometimes a new version has some bug/incompatibility that I want to avoid. While an unchanged version number might not mean much, a change in the version number might mean a lot.
And if it wasn't too much to ask, displaying also the current installed version would help a lot when looking at changelogs and deciding which updates are worthwhile and which ones can cause trouble.
Thanks for your time.
It would be nice to highlight which part of the upstream version changed and to include release number for package re-builds.
Important news from repo can also be shown to warn the user about maintenance periods and/or recent vulnerabilities.
Just as an example, this is how the version numbers appear on my Arch Linux system package manager:
flatpak remote-ls --updates gives you some info for the flatpaks that can be updated.
It doesn't show the currently installed version for each one, only the remote version, so you have to check that manually.
I wrote a small tool to get that information for me, maybe it'll be useful to someone else: https://github.com/ivanalejandro0/flatpak-update-checker/
It's nothing fancy, just combines the info from flatpak remote-ls --updates and flatpak list.
I think adding version information to the ostree commit metadata should be a prerequisite for this (I haven't assessed the feasibility of that). As it stands, the only source of remote ref versions is appdata that can be up to 24 hours out of date. flatpak update reporting the wrong version is worse than not reporting a version at all.
The duplicate issue #4515 had a milestone attached that was being put off each cycle. I don't think it makes sense to re-assign a milestone until there's a concrete plan.
I think your approach is reasonable. Each commit should be bounded to the application version, even if the changes only concern the Flatpak build config.
As a person used to Debian, .deb packages, Apt and Nala, this is really annoying!
I thought first that there must be translation problem for Discover (KDE's software center that handles installation / uninstallation and updating the programs), but I switched back to English and I see that it really says "Refresh" of the same version, as you can see in the above printscreen.
Then I thought it must be a bug in Discover that I need to report, but with a bit of search I got to this issue, which makes it clear that it's a problem in Flatpak itlself.
I'm not very fond of Flatpak and I prefer the native to Debian, .deb packages as they handle dependencies and space wasting better and they allow me to install them offline (in case something bad or very bad happens). Even though I don't like these kind of packages and the packing system very much, I consider that would be very good for me as I'm forced to use some Flatpak packages like Mission Center and Steam and for others to have this very annoying problem fixed. One less annoying problem is better for the adoption of Flatpak and Linux in general. So me and many others, most likely not on Github or being aware of this issue raised here, will appreciate this problem being fixed!
BTW, I might be wrong, but I think that when Debian maintainers release exactly the same version like from Program 3.2.1 -> 3.2.1, but they have fixed or changed something to the building process, they add a dash and number, like: Program 3.2.1-0 -> Program 3.2.1-1 They also do something with a number and colon in front, like 4:3.2.1 or 4:3.2.1-0, but I forgot what is the number in front for. Maybe you can do something similar to that. If you decide to keep the versions / number formatting similar to how Debian maintainers do it, then I guess it would be also easier for KDE or Gnome developers to better display the differences in version numbers, like highlight them one day.
