GNOME 43.4 is designed to be a very boring bugfix update for GNOME 43, so it should be a safe and uneventful upgrade from earlier versions of GNOME 43.
And I’ve noticed the entire 43 series, “rc” modules are being shipped in place of the final releases… why?
Not to mention it doesn’t have the latest evolution-data-server, gnome-control-center, vte, (among other) updates… by the time the next revision comes, those updates will be old news, and everyone is shipping them anyway. It just seems there is no coordination here.
Is there any particular reason why these releases are just a complete mess? I used to pull the folder to do builds for packaging, but I can’t for the life of me understand why 4 releases in, none of this has been addressed or anything. Is this automated? Are the final tarballs bad or something?
I’m confused by your comment because most of what you write is not true. Are you looking at a different release? Because your comments don’t really apply to this 43.4 release:
There are lots of changes in the NEWS file. Are you looking at a different NEWS file?
The only “rc” module left is gnome-backgrounds, which is not OK. It should have a .0 release. I’ll look into that now. There are no other “rc” modules.
I see it has evolution-data-server 3.46.4, the latest 3.46 version, gnome-control-center 43.4.1, the latest 43 version, and vte 0.70.2, which was the latest vte version uploaded to download.gnome.org before the tarball deadline for GNOME 43.4.
vte in particular is problematic because the git tags are created just before the tarball deadline, then the tarballs get created and uploaded some days later (if at all). We do not release git tags, only tarballs, and the vte 0.70.3 tarball was not uploaded until today. To get the latest vte included, the tarballs need to be released sooner.
There was an issue with the script that generates the NEWS file. Its fixed now. The tarballs/artifacts/checksums have stayed the same as yesterday and only the NEWS file should be different.
Boxes is an application, not a system service. The two are completely different.
Flatpak is for applications: things that run with low privileges, and contact other services. The Shell, system settings, and all the other parts of a desktop session are privileged components, and as such cannot be containerised or sandboxed.
GNOME is the desktop. It’s a desktop environment. That has nothing to do with whatever metaphor it does or does not implement.
Many parts of three certainly could be — especially Settings, which shouldn’t need to run with elevated privileges itself. But Flatpak isn’t necessary the right tool for that.
Settings is very much an edge case: yes, it runs as your user, but it also needs to deal with global settings which are not proxied by the settings portal, and would require direct access to the user configuration. Settings also has to talk to a lot of system and session services, which would require opening a lot of holes in the sandbox.
In practice, anything that is core to the GNOME UX will be very hard to sandbox in any meaningful way.