Since early KDE4, many of us, simple users, got used to consider only the last release of a branch. (4.B.5 generally, 4.B.6 exceptionally) Since the KDE team is sometimes stabilizing intermediate releases, it also got used to quickly drop from portage's tree the previous stable version. => 4.B.5/6 is dropped soon after the stabilization of < 4.B+1.5 Could it be possible to keep kde-4.B.5/6 available in portage's tree until kde-4.B+1.5/6 gets stabilized ? Reproducible: Always
(In reply to comment #0) > Since early KDE4, many of us, simple users, got used to consider only the > last release of a branch. (4.B.5 generally, 4.B.6 exceptionally) > > Since the KDE team is sometimes stabilizing intermediate releases, it also > got used to quickly drop from portage's tree the previous stable version. > => 4.B.5/6 is dropped soon after the stabilization of < 4.B+1.5 > > Could it be possible to keep kde-4.B.5/6 available in portage's tree until > kde-4.B+1.5/6 gets stabilized ? If the new kde version works pretty good, what is the point to leave the old ebuilds?
> If the new kde version works pretty good, what is the point to leave the old > ebuilds? Aesthetics ! I just love the concept of "penultimate stable" ! OK, more seriously : A/ The KDE production scheme. As you are certainly aware of, the KDE production scheme strictly follows a release schedule. Because the project does not run at infinite resources, such a production scheme means that a release is issued more because it is time to release than because the software is technically ready to be released. In other words, in terms of software quality, it means that 4.B.X<5, even if "pretty good workable" is necessarily of lesser quality than 4.B.5 Of course, if it was not the case, why would the KDE team go on releasing up to 5 on the same branch. Of course, the todo list as displayed on the feature plans also confirms this. Therefore : KDE 4.B.5 is better from a pure software quality standpoint that KDE 4.B+1.X<5 can be. B/ History of the package. The history of the package also confirms this since 4.2 with users repeatedly reporting regressions observed on 4.B+1.X<5 with regards to 4.B.5 This makes so that many users, more eager to use KDE for working with, than to test the new features have taken the habit to ignore all <5 releases. C/ Convenience Of course it is always possible for any user to keep the tree in his local overlay but I think that everyone will admit that maintaining locally the entire set of kde-base dependent packages + dependencies is not very handy and, in any case, represents a serious constraint for "real" kde users. D/ Maintenance Even if the process is made just easy by the Gentoo KDE team, upgrading kde-base is not something you can fire & forget ad libitum in a multi-user environment. This also leads many maintainers to skip intermediate versions, waiting for better days or, more frequently, waiting for a sync with a qt upgrade.
If we decide to stabilize a new version, certainly it does not work worse than the actual stable, otherwise this should be a non-sense. Also we don't like to keep non-maintained series.
Summarizing Ago: No. (We're actually very glad every time we can drop an old release, because it makes maintenance much easier.)
