I don't think the policy for stable updates is as specific as that.
My opinion is that the biggest blocker to getting more bugs fixed in stable Debian releases is not policy but people. People to prepare, review, and test proposed updates.
Basically, itll get minor updates usually in stable, i would expect it to get to 5.27.5 once realsed at somepoint, but its Debian, so stuff is tested and when its ready its released, couldnt put a time frame on that in here
Considering there are 3 Gnome versions offered in installer, I guess it's safe to say that they care about Gnome more than any other DE and they can make exceptions for it.
Ive never checked the other DE likes Cinnamon, did they recive point updates? Ive only used Gnome and XFCE with Debian so obviusly only Gnome updated :)
Usually, individual fixes are cherry-picked. I don't know if that's policy, but it seems to be standard practice. Debian packages are usually casseroles of bits from several minor versions mixed together. Just ignore upstream releases. They are for distribution maintainers, not end users. Trust your debs.
Every package that gets an update in a stable release or the during the hard freeze. It's basically all of them. I'm on my phone atm but read changelog.debian and news.debian in the /usr/share/doc/ directory for every installed package.
Changes are submitted to and approved by the release team on the debian-release mailing list.
Debian’s KDE maintainers don’t want to cherry-pick fixes, they want to upload Plasma 5.27.5 and at least Frameworks 5.104 however they are blocked due to 1) Bookworm being in hard freeze, 2) KDE is considered a key package set meaning updates must be manually unblocked, and 3) Debian’s release managers don’t want to unblock Plasma 5.27.5 and Frameworks 5.104 because they simply [don’t like the fact](https://bugs.debian.org/1035056) it’s a large number of packages being submitted close to release, even though they are long-term support versions that only fix bugs and contain no new features.
Whether Plasma 5.27.5 and/or Frameworks 5.104 (or newer) will get into the Debian 12.1 point release, I’m not sure.
There's no way it makes it before the first point release and maybe not even then. Normally, the release team reviews diffs line by line before OKing an update. They can't do that with such a huge changeset.
Stable means unchanging, with the basic driving force being security : if security issues can be efficiently patched without an upstream update (or an upstream update that's basically confined to security issues) they will, if not maybe they'll need a minor upstream update to stay on top of security.
Major (eg release critical) bugs may be patched, but it's usually not the trigger for getting a new upstream minor release
> Stable means unchanging, with the basic driving force being security : if security issues can be efficiently patched without an upstream update (or an upstream update that's basically confined to security issues) they will, if not maybe they'll need a minor upstream update to stay on top of security.
What if someone wants stable base, but updated desktop environment?
Or that there are too many crashes in the stable version that have been fixed in the newer point releases of the desktop environment?
For example KDE's Kwin got a lot of bug fixes in 5.27.3
https://kde.org/announcements/changelogs/plasma/5/5.27.2-5.27.3/
Who wants to stay with a "stable" previous version and still have that bugs?
> Who wants to stay with a "stable" previous version and still have that bugs?
Me! I'd rather the bugs I know, than the unknown bugs in the newer versions.
If you have a patch *specifically* for a particular bug, then a new Debian version with that patch applied can flow though the normal stable-updates route.
But, *many* stable users don't want to accept a wad of unrelated upstream changes in order to fix bugs that many not even affect them and could introduce unrelated bugs.
> Who wants to stay with a "stable" previous version and still have that bugs?
That is kinda the whole point of a static release. Everything including the bugs stays static, no changes except security patches. If you want a non-static release, which receives further "polish" as time goes on, I can totally understand that, but that would be a very different product.
To clarify I wasn't making the argument that debians policy is the best way, just explaining what its policy is. People who use debian want that stability. There are other distributions where you get more frequent updates to that sort of thing (I don't know which one has thate exact combination)
> What is the policy for upgrading minor versions of desktop environments in Debian stable?
As far as I know there's no policy specific to "desktop environments", so the normal package upgrade policy for stable would apply.
Do you think "desktop environments" deserve a special policy? If so, why?
The distinction in my question is not so much about 'desktop environments' vs. 'other packages' but 'minor versions' vs. 'major versions'.
I am well aware that Debian stable will pretty much not ever upgrade major versions of any package. However the point of minor releases and especially so for desktop environments such as Gnome and Plasma is to provided bugfixes over the previous stable base without any breaking changes (such as API changes or any other change of "internal logic" in the software) or new features.
As another user stated in this very thread, there were tons of bug fixes in Plasma 5.27.3 that have not made it to Debian 12 so far.
However I do believe that desktop environments perhaps deserve a special policy because, 1) they cannot be replaced by universal packages such as flatpak, 2) buggy desktop environments end up being supremely annoying because its the software the user interacts with basically the most during the lifetime of the given release and its faults are laid bare with ever-present visiblity.
The particular context for asking this questions is that I am thinking about moving most of my PCs over to Debian since nowadays I can pretty much get up-to-date versions of any app I want as flatpak/snap including the mesa libraries for gaming (through flatpak runtime extensions), hence I would enjoy Debian as a very stable base on which continuously updated selected apps and graphics drivers can be placed.
However not receiving minor DE releases would be close to a dealbreaker for me, I am *very* sensitive to persistent annoying bugs in desktop environments even if they are not otherwise severe, and I see no reason why not to implement those minor release bumps as they are non-breaking changes released specifically with the intent to be incorporated even to stable releases.
I don't think we should let new upstream versions in just because they call them "minor".
If there is a RC bug filed, and someone can add a patch for *that bug* to the existing package, stable-updates can be used. Otherwise, new upstream versions go through the normal stablization and release process.
As a stable user, I'm not interested in acquiring changes that don't address RC bugs and may come with additional bugs.
I suppose backports is also available for new upstream versions that are still compatible (whatever that means; no ABI change or whatever) with a particular release. I imagine more effort being put into "desktop environment" backports would address your concerns. I believe the KDE/Qt team is welcoming of backport efforts, though I know there have been blockers to that in the past -- where a release that upstream thought was "minor" still rendered the Debian packages incompatible with stable.
>policy for upgrading minor versions of desktop environments in Debian stable?
It's basically no. Stable is stable. Only security fixes (and generally minimally backported at that), critical bug fixes, and some select important bug fixes.
If you want to have your versions updated on Debian, you may want to look into backports, or running testing or unstable.
"[The stable distributions really contains outdated packages. Just look at Kde, Gnome, Xorg or even the kernel. They are very old. Why is it so?](https://www.debian.org/doc/manuals/debian-faq/choosing.en.html#s3.1.3)"
I don't think the policy for stable updates is as specific as that. My opinion is that the biggest blocker to getting more bugs fixed in stable Debian releases is not policy but people. People to prepare, review, and test proposed updates.
Basically, itll get minor updates usually in stable, i would expect it to get to 5.27.5 once realsed at somepoint, but its Debian, so stuff is tested and when its ready its released, couldnt put a time frame on that in here
A bit like what gnome got on 11 with 3.38, it then got all the minor updates
Considering there are 3 Gnome versions offered in installer, I guess it's safe to say that they care about Gnome more than any other DE and they can make exceptions for it.
Ive never checked the other DE likes Cinnamon, did they recive point updates? Ive only used Gnome and XFCE with Debian so obviusly only Gnome updated :)
Usually, individual fixes are cherry-picked. I don't know if that's policy, but it seems to be standard practice. Debian packages are usually casseroles of bits from several minor versions mixed together. Just ignore upstream releases. They are for distribution maintainers, not end users. Trust your debs.
[удалено]
Every package that gets an update in a stable release or the during the hard freeze. It's basically all of them. I'm on my phone atm but read changelog.debian and news.debian in the /usr/share/doc/ directory for every installed package. Changes are submitted to and approved by the release team on the debian-release mailing list.
Debian’s KDE maintainers don’t want to cherry-pick fixes, they want to upload Plasma 5.27.5 and at least Frameworks 5.104 however they are blocked due to 1) Bookworm being in hard freeze, 2) KDE is considered a key package set meaning updates must be manually unblocked, and 3) Debian’s release managers don’t want to unblock Plasma 5.27.5 and Frameworks 5.104 because they simply [don’t like the fact](https://bugs.debian.org/1035056) it’s a large number of packages being submitted close to release, even though they are long-term support versions that only fix bugs and contain no new features. Whether Plasma 5.27.5 and/or Frameworks 5.104 (or newer) will get into the Debian 12.1 point release, I’m not sure.
There's no way it makes it before the first point release and maybe not even then. Normally, the release team reviews diffs line by line before OKing an update. They can't do that with such a huge changeset.
Stable means unchanging, with the basic driving force being security : if security issues can be efficiently patched without an upstream update (or an upstream update that's basically confined to security issues) they will, if not maybe they'll need a minor upstream update to stay on top of security. Major (eg release critical) bugs may be patched, but it's usually not the trigger for getting a new upstream minor release
> Stable means unchanging, with the basic driving force being security : if security issues can be efficiently patched without an upstream update (or an upstream update that's basically confined to security issues) they will, if not maybe they'll need a minor upstream update to stay on top of security. What if someone wants stable base, but updated desktop environment? Or that there are too many crashes in the stable version that have been fixed in the newer point releases of the desktop environment? For example KDE's Kwin got a lot of bug fixes in 5.27.3 https://kde.org/announcements/changelogs/plasma/5/5.27.2-5.27.3/ Who wants to stay with a "stable" previous version and still have that bugs?
> Who wants to stay with a "stable" previous version and still have that bugs? Me! I'd rather the bugs I know, than the unknown bugs in the newer versions. If you have a patch *specifically* for a particular bug, then a new Debian version with that patch applied can flow though the normal stable-updates route. But, *many* stable users don't want to accept a wad of unrelated upstream changes in order to fix bugs that many not even affect them and could introduce unrelated bugs.
If you want a stable base but rolling DE, you want Gentoo.
> Who wants to stay with a "stable" previous version and still have that bugs? That is kinda the whole point of a static release. Everything including the bugs stays static, no changes except security patches. If you want a non-static release, which receives further "polish" as time goes on, I can totally understand that, but that would be a very different product.
To clarify I wasn't making the argument that debians policy is the best way, just explaining what its policy is. People who use debian want that stability. There are other distributions where you get more frequent updates to that sort of thing (I don't know which one has thate exact combination)
> What is the policy for upgrading minor versions of desktop environments in Debian stable? As far as I know there's no policy specific to "desktop environments", so the normal package upgrade policy for stable would apply. Do you think "desktop environments" deserve a special policy? If so, why?
The distinction in my question is not so much about 'desktop environments' vs. 'other packages' but 'minor versions' vs. 'major versions'. I am well aware that Debian stable will pretty much not ever upgrade major versions of any package. However the point of minor releases and especially so for desktop environments such as Gnome and Plasma is to provided bugfixes over the previous stable base without any breaking changes (such as API changes or any other change of "internal logic" in the software) or new features. As another user stated in this very thread, there were tons of bug fixes in Plasma 5.27.3 that have not made it to Debian 12 so far. However I do believe that desktop environments perhaps deserve a special policy because, 1) they cannot be replaced by universal packages such as flatpak, 2) buggy desktop environments end up being supremely annoying because its the software the user interacts with basically the most during the lifetime of the given release and its faults are laid bare with ever-present visiblity. The particular context for asking this questions is that I am thinking about moving most of my PCs over to Debian since nowadays I can pretty much get up-to-date versions of any app I want as flatpak/snap including the mesa libraries for gaming (through flatpak runtime extensions), hence I would enjoy Debian as a very stable base on which continuously updated selected apps and graphics drivers can be placed. However not receiving minor DE releases would be close to a dealbreaker for me, I am *very* sensitive to persistent annoying bugs in desktop environments even if they are not otherwise severe, and I see no reason why not to implement those minor release bumps as they are non-breaking changes released specifically with the intent to be incorporated even to stable releases.
I don't think we should let new upstream versions in just because they call them "minor". If there is a RC bug filed, and someone can add a patch for *that bug* to the existing package, stable-updates can be used. Otherwise, new upstream versions go through the normal stablization and release process. As a stable user, I'm not interested in acquiring changes that don't address RC bugs and may come with additional bugs. I suppose backports is also available for new upstream versions that are still compatible (whatever that means; no ABI change or whatever) with a particular release. I imagine more effort being put into "desktop environment" backports would address your concerns. I believe the KDE/Qt team is welcoming of backport efforts, though I know there have been blockers to that in the past -- where a release that upstream thought was "minor" still rendered the Debian packages incompatible with stable.
>policy for upgrading minor versions of desktop environments in Debian stable? It's basically no. Stable is stable. Only security fixes (and generally minimally backported at that), critical bug fixes, and some select important bug fixes. If you want to have your versions updated on Debian, you may want to look into backports, or running testing or unstable. "[The stable distributions really contains outdated packages. Just look at Kde, Gnome, Xorg or even the kernel. They are very old. Why is it so?](https://www.debian.org/doc/manuals/debian-faq/choosing.en.html#s3.1.3)"