I was playing around with the fedora provided flatpaks from registry.fedoraproject.org.
The thunderbird version I found there (and on fedora-testing) was 91.3.0, which seems rather old. Currently available in the usual rpm repos is 91.8.0, and even 91.7.0 has been available for a month.
From a somewhat recent entry on fedoramagazine I got the impression that the flatpaks on registry.fedoraproject.org were built from the regular fedora rpms, but maybe this building has changed and the flatpaks are now unmained?
Would be great to find out what’s going on here. The thunderbird version from flathub brings along an old gpg version, and old libgcrypt and who knows what other outdated library.
I understand based on your comment you are using Fedora 36 because, you said “91.7.0” for F37 and F35 we already updated to 91.8.0. Currently F36 package not push to stable(still in testing) because “final release is close” so we froze updates, so we can fix the version list.
No, I am using Fedora 35, that’s why I first listed 91.8.0. However, I have noticed that it is rather new, that’s why I mentioned that 91.7.0 is available for quite a while already and therefore I do not understand why the flatpak version is 91.3.0.
@thunderbirdtr I did a new trial. Installed a fresh Fedora 35. Then, as normal user, ran flatpak install fedora org.mozilla.Thunderbird and flatpak install fedora org.mozilla.Firefox.
I then started both apps with flatpak run org.mozilla.Thunderbird and flatpak run org.mozilla.Firefox.
Thunderbird reports version 91.3.0, firefox reports version 97.0.1.
Both versions are old. It seems to me as if fedora flatpaks are currently not well maintained.
EDIT: For firefox this is a known issue, see bugzilla.
I don’t know if they’re automatically rebuilt when we rebuild the rpms, I don’t think so.
What may be happening is that because most people are going straight to FlatHub for their Flatpaks (especially in cases where the Flatpaks need proprietary software support), package maintainers currently have less incentive to also keep the Fedora Flatpaks up to date along with the rpms. So, similar to packages, unless a package maintainer is also using the Flatpak version, they may not spend the same amount of time keeping the Flatpak build up to date. I also don’t think that It is necessary that the rpm package maintainers maintain the Flatpaks (I don’t maintain any Flatpaks for my rpms, for example, but I’m happy for others to step in and do it if they wish).
And that’s perfectly fine. In that case there is no Fedora flatpak to begin with, so no one expects anything there. I think the issue is when there is a flatpak, but there is no hint that it is outdated. I prefer things to fail with a loud bang instead of silently giving unexpected results.
Now I have tried what that means for Fedora Silverblue: Unsuspecting users using a default silverblue install and using gnome software to install for example thunderbird will silently get an outdated version. If thunderbird would simply not be present as a flatpak, then the user would look for the docs and find the instructions to enable flathub.
A word about flathub flatpaks and why I would prefer fedora flatpaks if they were up to date: Besides the difficulty of proprietary apps being commingled with free apps, some of the apps also tend to ship old (lts) versions of bundled software.
You will need to follow the same process here as we would for outdated rpms—file a bug to poke the maintainer to update (which you’ve done already). If it remains out of date, I expect we’d follow the “non responsive maintainer” process here also: