Apps that are in the bundle have inconsistent versioning; most use the bundle's own versioning scheme, but others use their own

I personally disagree this is a problem. It let's applications hop on and off the release and keep their versioning number intact.

The bundle's YY.MM version numbering scheme happens to be the same as Ubuntu's versioning scheme, which causes users to confuse one with another (for example a user with Kubuntu 18.04 is actually using KDE Applications 17.12, not 18.04)

I personally disagree this is a problem. Ubuntu didn't invent the YY.MM versioning scheme, on top of that our scheme only overlaps with Ubuntu's 1/3 of the times. Maybe Kubuntu can just put some extra work and make sure that for the .04 release they ship our .04 release if they feel that it confuses their users. Or maybe they could change their versioning scheme.

There are no LTS app versions the way there are with Plasma; distros that ship Plasma LTS get stuck with old apps versions that have bugs which have been fixed in later releases

I personally disagree this is a problem. If distributions want bug fixes they can either

• update to a new release
• do the work of doing an LTS branch themselves.
• give us money so we can hire someone to the work for them

If this comes from an application developer that wants to maintain 3 branches (LTS, stable, devel) it'd be another thing. Do we know of any developer that would like to maintain such scheme for KDE Applications?

IMNSHO the only real problem is the name is not good (your bullet points 1 and 3), we've known that for a long time, no one has been able to find a name that is better, I'll be happy if someone can find one :)

In T10812#182195, @aacid wrote:

Apps that are in the bundle have inconsistent versioning; most use the bundle's own versioning scheme, but others use their own

I personally disagree this is a problem. It let's applications hop on and off the release and keep their versioning number intact.

I'm using Dolphin 18.12.3, which comes from KDE Applications 18.12.3. But the bundle also comes with Okular. Am I using Okular 18.12.3? Or Okular 1.6.3? The promo material says 18.12.3. The version number in my distro's packaging says 18.12.3. Discover, which uses the distro packaging metadata, says 18.12.3. But the About Okular window says 1.6.3. This is confusing and problematic from a user, packager, and promo perspective because it's not clear which version number they should use.

In T10812#182195, @aacid wrote:

The bundle's YY.MM version numbering scheme happens to be the same as Ubuntu's versioning scheme, which causes users to confuse one with another (for example a user with Kubuntu 18.04 is actually using KDE Applications 17.12, not 18.04)

I personally disagree this is a problem. Ubuntu didn't invent the YY.MM versioning scheme, on top of that our scheme only overlaps with Ubuntu's 1/3 of the times. Maybe Kubuntu can just put some extra work and make sure that for the .04 release they ship our .04 release if they feel that it confuses their users. Or maybe they could change their versioning scheme.

If you're suggesting that Kubuntu could change their versioning scheme, that's a tacit admission that you do think there's a problem (otherwise there would be no suggestion of a proposed change or solution). It's a problem from a user perspective for just the reason I gave: users confuse our app versions with Ubuntu's own version numbers. "Confused users" is a problem. I agree that it's not a huge issue but I think it is an issue. Maybe it's not worth fixing. But it's an issue.

In T10812#182195, @aacid wrote:

There are no LTS app versions the way there are with Plasma; distros that ship Plasma LTS get stuck with old apps versions that have bugs which have been fixed in later releases

I personally disagree this is a problem. If distributions want bug fixes they can either

• update to a new release
• do the work of doing an LTS branch themselves.
• give us money so we can hire someone to the work for them

Updating to a new release isn't an option for the discrete release distros, particular for their LTS releases. Asking them to do an LTS branch themselves or pay us to do it is unreasonable; it's our software and we define our release schedule. All I'm saying is that I think adding LTS versions of apps is something that would be really nice for the discrete release distros that ship our LTS Plasma versions. Right now they can continuously take our LTS Plasma bugfix releases to ensure that the Plasma they ship gets better and better over time, but they can't do this for our apps. This isn't just bad for their users; it's bad for us because we need to handle more time-wasting bugzilla tickets for issues that have already been fixed from people using versions of our software that could be 2 or more years old.

If this comes from an application developer that wants to maintain 3 branches (LTS, stable, devel) it'd be another thing. Do we know of any developer that would like to maintain such scheme for KDE Applications?

I mean, that's what we do for Plasma and it's not a problem. In practice all it means is that when you have a bugfix, instead of landing it on the stable branch and merging to master, you land on the LTS branch, merge to the stable branch, and merge that to master. And in the few cases where it doesn't apply cleanly to the LTS branch, you say, "ehh, too much work, stable or master only" and life goes on. :) It's really not that hard.

In T10812#182201, @ngraham wrote:

If you're suggesting that Kubuntu could change their versioning scheme, that's a tacit admission that you do think there's a problem (otherwise there would be no suggestion of a proposed change or solution). It's a problem from a user perspective for just the reason I gave: users confuse our app versions with Ubuntu's own version numbers. "Confused users" is a problem. I agree that it's not a huge issue but I think it is an issue. Maybe it's not worth fixing. But it's an issue.

As i clearly said I don't think it's a problem, but if KUbuntu developers think it is, it is something they have the power to fix by themselves.

In T10812#182195, @aacid wrote:

There are no LTS app versions the way there are with Plasma; distros that ship Plasma LTS get stuck with old apps versions that have bugs which have been fixed in later releases

I personally disagree this is a problem. If distributions want bug fixes they can either

• update to a new release
• do the work of doing an LTS branch themselves.
• give us money so we can hire someone to the work for them

Updating to a new release isn't an option for the discrete release distros, particular for their LTS releases. Asking them to do an LTS branch themselves or pay us to do it is unreasonable; it's our software and we define our release schedule. All I'm saying is that I think adding LTS versions of apps is something that would be really nice for the discrete release distros that ship our LTS Plasma versions. Right now they can continuously take our LTS Plasma bugfix releases to ensure that the Plasma they ship gets better and better over time, but they can't do this for our apps. This isn't just bad for their users; it's bad for us because we need to handle more time-wasting bugzilla tickets for issues that have already been fixed from people using versions of our software that could be 2 or more years old.

No, we just need to get users away from bad distros. I'm 92.41% sure those distros don't have any issue updating to a new firefox or chrome when it comes out. But on the other hand they want us to do extra work for some weird rule, i say NO, they are the problem and we have to fight back. Distributions decided they don't want to give users updates, they have to live with that. Users decided they want to use a distribution that doesn't give them updates, they have to live with that or change to a better distribution or use snap/flatpak (a story we have to improve at some point)

If this comes from an application developer that wants to maintain 3 branches (LTS, stable, devel) it'd be another thing. Do we know of any developer that would like to maintain such scheme for KDE Applications?

I mean, that's what we do for Plasma and it's not a problem.

Comparing Plasma and KDE Applications is like comparing RedHat with BlueSystems, the amount of developer-power per line Plasma has compared to KDE Applications is probably several orders of magnitude bigger, so what works in one doesn't necessarily have to work in another case.

In T10812#182213, @aacid wrote:

No, we just need to get users away from bad distros.

I find this really insulting. :/ I think discrete release distros can be great.

It's also unrealistic. The "bad distros" are the ones actually used by huge numbers of people. In my last job, almost all the engineers used Linux on their desktop. Did they use Arch? No. OpenSUSE Tumbleweed? No. They all used CentOS or Ubuntu LTS versions, because those are the distros that their enterprise customers are using. We can't increase our market penetration by ignoring these distros. Please correct me if I'm wrong, but one of the major reasons why we do releases in the first place is for the benefit of distros. If they wanted to, they could just package snapshots of our sources, right? We're already providing a nice-to-have service by even doing releases.

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?")

In T10812#182242, @cfeck wrote:

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.

I was actually going to suggest this myself, so I'm glad you did. :) I agree 100% with this as well as your other ideas about splitting up apps into different releases.

In T10812#182245, @ngraham wrote:

In T10812#182242, @cfeck wrote:

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.

I was actually going to suggest this myself, so I'm glad you did. :) I agree 100% with this as well as your other ideas about splitting up apps into different releases.

We have been trying hard to sell those applications as not "part of KDE (Plasma)" (DE agnostic, OS agnostic). That would be a huge step back. Big -1.

Yes, we have been trying hard, but did we succeed? Would someone just stop using Okular, because it is shipped with the Plasma bundle instead of the KDE Applications bundle?

Also, does "Discover" or "Bluedevil" really only work under Plasma?

In T10812#182252, @cfeck wrote:

Yes, we have been trying hard, but did we succeed? Would someone just stop using Okular, because it is shipped with the Plasma bundle instead of the KDE Applications bundle?

I fear it will happen, yes. Moreover, Plasma bits tend to update their dependecies on base libraries (Qt and Frameworks) at a faster pace than most of the other components. But more important than that it's the branding issue (which why I advocate a change of the name of the bundle).

Also, does "Discover" or "Bluedevil" really only work under Plasma?

That's what the Plasma team decided, and they can decide otherwise. They decided (with reasons) that those components are tightly integrated with the rest of Plasma. This can change, of course; other components were moved out of Plasma over time.

The discussion about LTS applications it's totally different. No one forces us to provide LTS releases, and from a resource point of view it does not make much sense: most of the applications per of the bundle are independent enough from each other and they don't bump their requirements frequently, so they could be updated by distributions should their policy allow that. But many of them can provide semi-official repositories with updates.
Talking about CentOS, the direction there is clear: flatpak.

In T10812#182253, @ltoscano wrote:

In T10812#182252, @cfeck wrote:

Yes, we have been trying hard, but did we succeed? Would someone just stop using Okular, because it is shipped with the Plasma bundle instead of the KDE Applications bundle?

I fear it will happen, yes.

In fact we don't have to fear or guess: we can just look at GNOME. They distribute their apps alongside GNOME itself. They share a release schedule and version numbering schema, and many of them even have "GNOME" in their name (e.g. "GNOME Chess", "GNOME Photos", etc). Despite this, I see no indication that people confusedly think you can't use GNOME's apps without the GNOME DE itself. People seem to happily use GNOME apps on whatever DE they want. Logically I think this makes sense because if you open up an app store app like Discover or GNOME Software, you generally see no indication of which parent DE an app is released alongside. If I crack open Discover and check out Simple Scan or GNOME Disks, nothing there tells me that I need all of GNOME to run it. So I don't think this is actually a problem.

In T10812#182253, @ltoscano wrote:

In T10812#182252, @cfeck wrote:>>

Also, does "Discover" or "Bluedevil" really only work under Plasma?

That's what the Plasma team decided, and they can decide otherwise. They decided (with reasons) that those components are tightly integrated with the rest of Plasma. This can change, of course; other components were moved out of Plasma over time.

To clear up a misconception, Discover doesn't depend on Plasma. In fact I believe it's being used in Lubuntu right now.

In T10812#182255, @ngraham wrote:

e "GNOME" in their name (e.g. "GNOME Chess", "GNOME Photos", etc). Despite this, I see no indication that people confusedly think you can't use GNOME's apps without the GNOME DE itself. People seem to happily

For KDE software it happend *so many times* over the course of the years:

• "App XXX is cool but I don't want to install KDE"
• "I don't need KDE, so I won't use App YYY"

This was the first, real reason the rebranding was agreed upon.
And for example in openSUSE we have people that use KDE applications with totally different setups (e.g. XFCE).

In T10812#182242, @cfeck wrote:

[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.

This bit I have to strongly disagree with. Sure, KF5 is not at the same level of Qt, but it's far from not being used externally. Here's just three examples for a single niche framework (syntax highlighting) from the top of my head:

• https://cullmann.io/posts/qt-creator-4-9-uses-ksyntaxhighlighting/ (QtCreator)
• https://kate-editor.org/2018/10/21/mit-licensed-ksyntaxhighlighting-usage/ (AbsInt)
• https://github.com/KDAB/GammaRay/blob/master/CMakeLists.txt#L540 (GammaRay)

All three have resulted in useful upstream contributions btw.

In T10812#182201, @ngraham wrote:

In T10812#182195, @aacid wrote:

Apps that are in the bundle have inconsistent versioning; most use the bundle's own versioning scheme, but others use their own

I personally disagree this is a problem. It let's applications hop on and off the release and keep their versioning number intact.

I'm using Dolphin 18.12.3, which comes from KDE Applications 18.12.3. But the bundle also comes with Okular. Am I using Okular 18.12.3? Or Okular 1.6.3? The promo material says 18.12.3. The version number in my distro's packaging says 18.12.3. Discover, which uses the distro packaging metadata, says 18.12.3. But the About Okular window says 1.6.3. This is confusing and problematic from a user, packager, and promo perspective because it's not clear which version number they should use.

What about an hybrid versioning system for the apps?
Perhaps something like "Okular 1.6.3, distributed with KDE Applications 18.12.3", something that remarks that Okular has an individual release cycle, but this version comes from KDE Applications 18.12.3 bundle.

In T10812#182284, @jtamate wrote:

In T10812#182201, @ngraham wrote:

In T10812#182195, @aacid wrote:

Apps that are in the bundle have inconsistent versioning; most use the bundle's own versioning scheme, but others use their own

I personally disagree this is a problem. It let's applications hop on and off the release and keep their versioning number intact.

I'm using Dolphin 18.12.3, which comes from KDE Applications 18.12.3. But the bundle also comes with Okular. Am I using Okular 18.12.3? Or Okular 1.6.3? The promo material says 18.12.3. The version number in my distro's packaging says 18.12.3. Discover, which uses the distro packaging metadata, says 18.12.3. But the About Okular window says 1.6.3. This is confusing and problematic from a user, packager, and promo perspective because it's not clear which version number they should use.

What about an hybrid versioning system for the apps?
Perhaps something like "Okular 1.6.3, distributed with KDE Applications 18.12.3", something that remarks that Okular has an individual release cycle, but this version comes from KDE Applications 18.12.3 bundle.

This sounds like a good solution to me. It allows users to easily find out when their version of Okular was released without needing to look it up and if an application drops out of the bundle the remark can simply be removed. I don't know how hard this would be to achieve technically (given that these dialogs are automatically generated as far as I am aware).

Small question regarding bug reports: would those still keep the versioning scheme of the application itself (that's the current state)? Or would it be more obvious for users to report a bug against, say, Okular 19.04?

In T10812#182215, @ngraham wrote:

In T10812#182213, @aacid wrote:

No, we just need to get users away from bad distros.

I find this really insulting. :/

That is your personal problem, i didn't insult you at all.

I think discrete release distros can be great.

That's fine, i don't totally agree, but i don't feel insulted by our disagreement.

It's also unrealistic. The "bad distros" are the ones actually used by huge numbers of people. In my last job, almost all the engineers used Linux on their desktop. Did they use Arch? No. OpenSUSE Tumbleweed? No. They all used CentOS or Ubuntu LTS versions, because those are the distros that their enterprise customers are using. We can't increase our market penetration by ignoring these distros.

Those distros are 450 years old, having an LTS version of KDE Applications is not going to help either. you'd need *a lot* of LTS versions, Ubuntu 16.04 still supported until next year has KDE Applications 15.12.

RHEL 7 (that i guess that will be supported for a while still) has 4.10.5

So i don't see how we can catter to those distributions with *one* LTS version, flatpak is the right answer for them in my opinion.

Please correct me if I'm wrong, but one of the major reasons why we do releases in the first place is for the benefit of distros. If they wanted to, they could just package snapshots of our sources, right? We're already providing a nice-to-have service by even doing releases.

I am not old enough to answer why we started doing releases, but if you ask my opinion, no we don't do releases for distros, we do releases for us, having a "this is x.y.z" point makes it easier when talk to users when they report bugs, etc.

In T10812#182242, @cfeck wrote:

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?")

This is a very radical proposal :)

Problems i see :

• moving back applications to desktop release is not a good idea
• 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.
• 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

Yeah let's not split things out into more release bundles just for the sake of it, that increases work for no gain.

The version number issue I doubt we'll get agreement on. I do strongly feel that unified versions for apps in KDE Applications is a necessary thing because distros use that for their current packages anyway and in the new world we need to give a version number in appstream which gets used in the snap/flatpak/appimage packages else it's just blank in Discover. But I doubt we'll get consensus there.

I propose we rename KDE Applications to KDE Apps Bundle. This is cooler and reduces confusion about apps that are not in the bundle.

Phab is a great way to hide discussions. There's no tags for this discussion and I'm not on any project associated with it. I've only just found this thread. Sometimes a mailing list is still the best solution.

In the meantime can we read the version number from CMake or some other parse-able app-specific location?

From my perspective as the author of the usability & Productivity reports it's really useful to be able to know what the future version of an app will be so I can accurately announce what release a given bugfix or feature will make it into. With the predictable MM.YY numbering scheme, this is easy. When each app has its own version number though, it's no longer predictable or even knowable, since each app might have its own custom version numbering scheme or decide to make something a new major version at any time.

This is a very radical proposal :)

Yes :) Either we don't change what we did the last 5 years, or we take a step back, and look at the big picture. What did we want to archive, and did we succeed? Where are resources well spent, both on our side, as well as on application maintainers side, and distributions side? I believe our faster release cycles (down from 6 to 4 months), as well as the three separate released products have actually increased our workload and that of distributions.

moving back applications to desktop release is not a good idea

I could also state that having basic applications released separately from "KDE" is not a good idea. How do you explain to users why an application manager is part of the "desktop", but a file and archive manager is not? Is a user manager a separate application or part of the "desktop"? What about a partition manager? All those applications are part of a Windows release, because they are considered (visible) part of an operating system. After all, people see "KDE" as their GUI for Linux.

wait for a whole year for the bugfix we just made there gets released

Sorry, I wasn't clear. I was talking about feature releases, what we currently do three times a year. They would be sufficient every 6, 8, or 12 months. We would still do monthly updates for bug fixes and translation additions.

This adds 3 more "release groups".

KDE Edutainmaint and KDE Extras would get released together, maybe every 8 or 12 months, with monthly updates. Plasma, together with Frameworks and base applications every 4 months, with Fibonacci weeks updates. For the projects that have maintainers, they decide how fast to make feature releases, but the stable branches could be released monthly automatically (even if it is just for translation updates).

our release team small enough

Exactly. That's why I was proposing to release all of KF5+Plasma+base apps together. Then we have more release people available. I've seen David doing KF5 releases alone the last 5 years. You did the same with Apps before I've spotted you near burning out. Give David a break and let us join forces.

In T10812#182282, @vkrause wrote:

Here's just three examples for a single niche framework (syntax highlighting) from the top of my head:

• https://cullmann.io/posts/qt-creator-4-9-uses-ksyntaxhighlighting/ (QtCreator)
• https://kate-editor.org/2018/10/21/mit-licensed-ksyntaxhighlighting-usage/ (AbsInt)
• https://github.com/KDAB/GammaRay/blob/master/CMakeLists.txt#L540 (GammaRay)

Someone not familiar with these companies might see that as a success. Those who are familiar know that both KDAB, as well as Qt are two-decade long supporters of KDE. As for the third contributor, I doubt it would know/use KDE software if you wouldn't work for them.

But KSyntaxHighlighting is a bit special. All other syntax highlighting engines I know are for the web (written in scripting languages), so our offering indeed fills a niche.

As an intermediate step, if we put the Frameworks on the Plasma schedule, we wouldn't necessarily need to blobify them into one big framework again; they could continue to be separate, but just use the Plasma release schedule.

From a code perspective, this would eliminate a whole class of issues we currently face where a feature or bugfix requires changes to both a Framework and Plasma. Right now these kinds of changes must be carefully planned and often require ifdefs or delaying the commit. It also makes life difficult for LTS distros because they don't get bugfixes to the Frameworks version they shipped with unless they have someone who basically browses the code full-time and cherry-picks fixes. Whereas with Plasma, they can just grab the source tarball of the bugfix releases and ship updates. If Frameworks moved to the Plasma release schedule, those distros could do that with Frameworks too, making it easier to ensure a higher level of quality for their users.

In T10812#184405, @ngraham wrote:

As an intermediate step, if we put the Frameworks on the Plasma schedule, we wouldn't necessarily need to blobify them into one big framework again; they could continue to be separate, but just use the Plasma release schedule.

From a code perspective, this would eliminate a whole class of issues we currently face where a feature or bugfix requires changes to both a Framework and Plasma. Right now these kinds of changes must be carefully planned and often require ifdefs or delaying the commit. It also makes life difficult for LTS distros because they don't get bugfixes to the Frameworks version they shipped with unless they have someone who basically browses the code full-time and cherry-picks fixes. Whereas with Plasma, they can just grab the source tarball of the bugfix releases and ship updates. If Frameworks moved to the Plasma release schedule, those distros could do that with Frameworks too, making it easier to ensure a higher level of quality for their users.

That might be true for Plasma, but it would worsen the situation considerably for anyone else IMHO. While it now takes ~4w until a KF5 fix is released, or a new feature becomes available for application developers, this would then take 3-4x longer. So we'd probably end up syncing the Application release cycle as well to mitigate this, and following that we'd probably also end up depending on unreleased Frameworks in both Plasma and Application master branches (something not particular popular with Application developers at least). We've been there before, in KDE3 times.

Frameworks has its own release schedule and that works well. Plasma fits in with that not the other way round.

For version numbers I think we should do as I did in Plasma and define some cmake variables to get used then go through all the apps where nobody much cares and set them to use the kde applications version number. We can find out which apps have maintainers who want it to have their own version number and work out a sensible cmake syntax for that if it's useful.

In T10812#184409, @vkrause wrote:

That might be true for Plasma, but it would worsen the situation considerably for anyone else IMHO. While it now takes ~4w until a KF5 fix is released, or a new feature becomes available for application developers, this would then take 3-4x longer. So we'd probably end up syncing the Application release cycle as well to mitigate this, and following that we'd probably also end up depending on unreleased Frameworks in both Plasma and Application master branches (something not particular popular with Application developers at least). We've been there before, in KDE3 times.

If Frameworks used the Plasma release cycle, then there would be bugfix releases as well, so you wouldn't have to wait four months if anything was broken. In fact, you would get any quickly-committed fixes faster than you do right now since the first Plasma bugfix release is only one week after the release of the last major version. By contrast, right now you need to wait a whole month to get a fix for something broken in Frameworks that's discovered soon after release (unless the packagers want to re-spin something).

In T10812#184372, @ngraham wrote:

In the meantime can we read the version number from CMake or some other parse-able app-specific location?

As mentioned (probably somewhere else) we already have such code in release-tools/add-bugzilla-versions/add-versions.py

In T10812#184400, @cfeck wrote:

wait for a whole year for the bugfix we just made there gets released

Sorry, I wasn't clear. I was talking about feature releases, what we currently do three times a year. They would be sufficient every 6, 8, or 12 months. We would still do monthly updates for bug fixes and translation additions.

That's still terrible, it totally kills my motivation if something i am thinking to work on on may not reach users in 2 years if i'm unlucky with my planetary alineation of a 12 month release cycle + distro release cycle.

If you have a new feature in Application X, and cannot wait Y months for a feature release, why not release it separately, at least once? Later it can be picked up for monthly releases in the bunde.

Because that means that people actually need to learn to release applications, which is something we/they don't want

It also upsets distribution packagers because suddenly the release cycle is not predicable and they can't adjust their workplan to our schedule and also upsets translators for the same reason, etc.

I just don't see a reason to tell people "your app sucks so we're going to release it less often"

In T10812#184411, @jriddell wrote:

Frameworks has its own release schedule and that works well. Plasma fits in with that not the other way round.

For version numbers I think we should do as I did in Plasma and define some cmake variables to get used then go through all the apps where nobody much cares and set them to use the kde applications version number. We can find out which apps have maintainers who want it to have their own version number and work out a sensible cmake syntax for that if it's useful.

Which is exactly what already happens.

the add-bugzilla-versions/add-versions.py uses a variable called BUGZILLA_APPLICATION_VERSION but I don't see that in any application, what's a good example?

Which is exactly what already happens.

I see for example:
Parley has
CMakeLists.txt:set(KDE_APPLICATIONS_VERSION_MAJOR "19")
CMakeLists.txt:set(KDE_APPLICATIONS_VERSION_MINOR "03")
CMakeLists.txt:project(parley VERSION ${KDE_APPLICATIONS_VERSION})

config-parley.h.cmake #define PARLEY_VERSION_STRING "@parley_VERSION@"

src/main.cpp: KAboutData aboutData(QStringLiteral("parley"), ki18n("Parley").toString(), PARLEY_VERSION_STRING );
src/main.cpp: QApplication::setApplicationVersion(PARLEY_VERSION_STRING);

So that probably needs a going over to see if there's other apps in KDE Applications which could be using that system, e.g. I was looking at Bovo and it didn't.

And adding use of appstream-metainfo-release-update to increase_repos_version.sh for those apps

In T10812#184446, @jriddell wrote:

the add-bugzilla-versions/add-versions.py uses a variable called BUGZILLA_APPLICATION_VERSION but I don't see that in any application, what's a good example?

Where do you see BUGZILLA_APPLICATION_VERSION being used?

ah the readme, the readme is broken.

The actual script parses the version from the project() cmake call since https://cgit.kde.org/sysadmin/release-tools.git/commit/add-bugzilla-versions?id=71e0e45de04e08081d8ef81bef22c5aa9e16805f i guess @adrianchavesfernandez forgot to update the readme

Adrián can you please propose a patch to fix the readme? Or maybe @jriddell you want to do it?

example app switched to common version scheme https://phabricator.kde.org/D21091 many apps already follow this, needs checking with maintainers and teams if it's wanted for other apps which could be switched.

Can add-bugzilla-versions/add-versions.py be adapted to do the appstream-metainfo-release-update ?

I'm not sure I trust myself to patch the README, as we can see I'm still learning all this :)

LTS distros can upgrade software to new releases. RHEL regularly does this for some components, such as GNOME, lately even Qt (Qt 5 was upgraded from 5.6 LTS to 5.9 LTS in RHEL 7, I'd hope they'll do 5.12 LTS too at some point, though with RHEL 8 having been released, they might also stop upgrading RHEL 7 that way, so I don't know). What components they do that with is purely a policy decision.

RHEL has never been upgrading the KDE project's software that way, but that's because they always considered it something they have to but don't actually want to maintain. Now they kicked it out entirely, so it will be maintained by the community in EPEL, hopefully in a more useful way. (That said, you can't really just upgrade a distribution that shipped with Plasma 4 to Plasma 5, so RHEL 7 would have been stuck either way. It would make sense to make the last release series of a first-digit major version an LTS. Similarly, upgrading KDE Applications as a whole was also problematic in the transition period where every release branch would port more applications from kdelibs 4 to KF5, even the upgrade-friendly Fedora only did partial upgrades of KDE Applications in stable releases during that period.)

release-tools/add-bugzilla-versions/README.rst updated, sorry :)

There are a lot of good points in the various posts here -- can they be taken to some of the lists where concrete decisions and actions can be taken? As @jriddell said, it's rather hidden here, but I think pretty important. KDE-community or KDE-devel for some, Distributions or KDE-Packagers for other parts?

For the record, I like the suggestion of KDE Apps Bundle, and spelling out the versioning more for users, if that can be done programmatically.

The discussion has been moved to release-team@kde.org. I guess we can close this and maybe involve some more mailing lists like kde-community to get a wider assortment of opinions.

[spam comment removed by sysadmin]