Try whatever ublue floats your boat, it all happens in the background, the power of atomic updates baby, if something breaks, just go back to the previous one…
apparently fools consider a finished app “dead” or “abandoned” if there isn’t a new release every week. so yeah, dev’s will just change a comment to not have their apps shunned
The point of my original post was that their update cadence is slower. The point of my followup reply is that they are not devoid of updates, either.
They have a release every 1-2 years, and it's packed full for various tweeks, improvements, and new features. They fix broken shit, and enhance where it makes sense.
I don't need my window manager to get fad features, and I don't need constant updates. It does what I want it to do already.
I have Debian on my servers for a decade or so, and on several workstations. My past experience doesn’t quite reflect that. The Debian guys and gals have always been pretty quick with patching the vulnerabilities. Like outstanding fast.
There is some merit to the bugfixing. But that’s kind of the point of Debian Stable(?!) Like in the meme picture of this post I don’t want updates each day. And I also don’t want the software on my servers to change too much on their own. I know my bugs and have already dealt with them and I’m happy that it now works seamlessly for 6 months or so…
And that’s also why I have Debian Testing on my computer. That gives me sort of an unofficial rolling distro. With lots of updates and bugfixes. I mean in the end you can’t have no updates and lots of updates at the same time. It’s either - or. And we can choose depending on the use-case. (I think the blame is on the admin if they choose a wrong tool for a task.)
You do have to worry about some things though. I couldn’t say what those things are, but I have a hunch that temple_os users have some pretty unique worries.
I had been wondering about that too so I looked it up and apparently it’s just what discover displays whenever there’s an update that doesn’t change the version number which is things like rebuilds with a newer compiler. Very confusing wording, I feel like just “update of version [version]” would be less confusing
Yeah, but in the context of flatpak isn’t the distribution managed by the developer themselves? Also, in the distro release version case, they usually add something distro specific to differentiate it.
isn’t the distribution managed by the developer themselves?
No, most often it’s not.
Valve literally just had a fiasco with them not long ago with them falsely marking steam as verified when Valve are not the ones packing the Flatpak.
I’m not sure about specific packages, but in general a packager may not want to increase the upstream version even if they can do it themselves - for example, they may have made some mistake in the packaging process.
Yes, and hence my comment on flatpak which turns out is false (that the upstream developer is usually the distributor/packager too). And the other still applies, distro usually adds a specific tag anyway for their refresh. Like that one time xz on rolling debian was named something x.y.z-really-a.b.c.
I think flatpak packagers should also append the specific tag too if that is the case. Like, x.y.z-flatpak-w where w can be the build release version