cfeck added a comment.
I agree with Albert.
The actual problem is that users still think that there is one "KDE version".
They are looking at the "About KDE..." menu to find the version of the KDE
(applications).
If you are asking for my personal opinion, I propose to split current KDE
Applications into parts:
- Base/essential applications (Dolphin, Ark, KCharSelect, KCalc, Kate/KWrite,
Konsole, Spectacle, Gwenview, Okular, thumbnailers, more?). Ship them together
with Plasma[1]. I really love the Fibonacci release cycles of Plasma for bug
fixes. Also, Plasma developers sometimes decide to do an LTS release, and the
base applications would also benefit from LTS support. All of them should use
the same 5.x (later 6.x) version number.
- KDEPIM (Kontact, Akonadi, etc.). It's a separate big project that could
benefit from either faster (for bug fixes) or smaller release cycles (for
feature releases). With the huge amount of work that Laurent is doing, I
sometimes feel he could better decide when he thinks a partical snapshot is
ready for release. Rushed commits for Akonadi also sometimes make KDEPIM
unstable. Reports on IRC that KDEPIM broke from one version to another
accumulate. More time for stabilization would really help. Regarding version
numbers, KDEPIM long used the 5.x versions. "Marketing" name could be "KDE
PIM", "KDE Kontact", or whatever.
- Maintained applications (such as Lokalize, Cantor, Kdenlive) get their own
releases, decided by the maintainers[2]. If maintainers failed to do a new
release within, say, 8 or 12 months, the project would move to "KDE Extras"
(see below) and last known working branch would in turn get scheduled (bundled)
maintainance updates. If someone steps up again to do separate releases, they
remove it again from "KDE Extras" to avoid scheduled releases.
- KDE Edutainment, all games and educational apps, which are all practically
unmaintained, and could need a slower release cycle, maybe back to two or even
one per year. Version numbers would be individual, but the bundle would be
called "KDE Edutainment YY.MM".
- KDE Extras (not to be confused with Extragear): Basically all the rest from
KDE Applications, minus the already listed packages. These would include rarer
stuff such as K3b, KWave, etc. In other words, everything else, which has no
one to do releases. Again, they would be released twice or once per year, each
one with their own version number, but the bundle called "KDE Extras YY.MM".
The proposed juggle between maintained applications and unmaintained (but
still useful and working) applications would also solve the "Extragear
problem". Either an application has a maintainer doing separate releases (e.g.
KMyMoney, LabPlot, Tellico), or they don't, and the project would automatically
join "KDE Extras" (e.g. KTorrent or Choqok; they have no maintainer, but fixes
are piling up).
Footnotes:
[1] I would even go as far and to also merge KF5 Frameworks - after all these
years we have to admit that the "Frameworks idea" (people using them outside of
KDE) has never materialized. All people currently doing Plasma, Apps, and KF5
releases could turn around to do the new "Plasma" releases. Give users the "old
KDE" back, but only with selected base applications.
[2] When I was proposing to split KStars from the bundle, I really feared
that the project would starve. What happened is the reverse: I see more
phabricator requests for KStars than ever before. Cantor might also benefit
from a separate release cycle. I believe the KDE Applications release cycle
hindered Kdenlive development ("should we merge now or wait another four
months?")
TASK DETAIL
https://phabricator.kde.org/T10812
To: ngraham, cfeck
Cc: cfeck, aacid, #yakuake, #okular, #dolphin, #kate, #spectacle, #konsole,
#gwenview, #kde_pim, #kde_games, #kde_applications, ngraham
