<table><tr><td style="">aacid added a comment.
</td></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/T10812#182242" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">T10812#182242</a>, <a href="https://phabricator.kde.org/p/cfeck/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@cfeck</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>I agree with Albert.</p>

<p>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).</p>

<p>If you are asking for my personal opinion, I propose to split current KDE Applications into parts:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">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.</li>
<li class="remarkup-list-item">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.</li>
<li class="remarkup-list-item">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.</li>
<li class="remarkup-list-item">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".</li>
<li class="remarkup-list-item">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".
<br /><br />
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).
<br /><br />
Footnotes:
<br /><br />
[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.
<br /><br />
[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?")</li>
</ul></div>
</blockquote>

<p>This is a very radical proposal :)</p>

<p>Problems i see :</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">moving back applications to desktop release is not a good idea</li>
<li class="remarkup-list-item">Having "less maintained" applications released less often is not a good idea, the fact that no bugfixes have been made in po2xml in years doesn't mean i want to wait for a whole year for the bugfix we just made there gets released.</li>
<li class="remarkup-list-item">This adds 3 more "release groups". Our release calendar is already ultra crowded and our release team small enough, so i'm not sure that'd really work out</li>
</ul></div></div><br /><div><strong>TASK DETAIL</strong><div><a href="https://phabricator.kde.org/T10812">https://phabricator.kde.org/T10812</a></div></div><br /><div><strong>To: </strong>ngraham, aacid<br /><strong>Cc: </strong>xyquadrat, jtamate, vkrause, lbeltrame, ltoscano, cfeck, aacid, Yakuake, Okular, Dolphin, Kate, Spectacle, Konsole, Gwenview, KDE PIM, KDE Games, KDE Applications, ngraham<br /></div>