I disagree.

• The version number is prominently displayed inside the application. We even changed Frameworks to make sure that the version number is well visible in the first tab, because the version has been hidden on the second tab of the About dialog for a while.
• KDE Applications is an bundle of loosly-coupled application, good for logistical reasons (less release work on each developer), but as it happened applications can go in and out anytime. Going out may make the original version useless and have more impact on packagers (epoch).
• the internal version can be still found
• there shouldn't be a consistent version inside KInfoCenter and I would oppose it even if all applications in KDE Applications had the same version number. The applications part of KDE Applications don't belong there, otherwise why shouldn't we list everything released by us with its own release cycle?
• there is no extra burden for the developers who freely choose to keep their version number
• about the version number in the release can be probably solved - we already have some magic to create the bugzilla versions.

I would find it more useful for branding purposes and less confusing to find a better instead of the confusing "KDE Applications".

In T10755#180932, @ltoscano wrote:

• about the version number in the release can be probably solved - we already have some magic to create the bugzilla versions.

Would you be interested in helping with this? We're a bit stuck in T10636. The idea is that we'd like the release process to automatically populate the AppData files' release tags.

My gut reaction was to agree with @ltoscano whole-heartedly, but the more I think about it that stance does have awkward unsolved problems.

The red flag is "Going out may make the original version useless and have more impact on packagers (epoch)" - we shouldn't make things worse for users for the sake of packager convenience, that defeats the point of releasing software for use.

The Apps version number is what we announce, promote, etc. It's what users mentally deal with. It's what they read about, look forward to, want to update to, find references to online, etc. The argument that it is what should show up in package managers and About dialogs is quite strong. So initially I thought "We just need to slap Released-with-apps-<foo> as a second line into the About dialog", but that won't fix what you see in package managers.
the pain

That said, Luigi is right that an app exiting the bundle is forever locked into continuing with a YY.MM version numbering scheme then so their semver keeps increasing. That's pretty meh, but users may not care.

e.g. Kate and KWrite did switch a long time ago to the application version numbers.

Two main reasons:

1. I forgot to update the own versions "very very very" often.
2. It was highly confusing as people talk about version x in most cases without large differentiation about KDE applications, application, frameworks, ... Less numbers, less confusion ;=)

But that is only my opinion ;=)

In T10755#180935, @ngraham wrote:

In T10755#180932, @ltoscano wrote:

• about the version number in the release can be probably solved - we already have some magic to create the bugzilla versions.

Would you be interested in helping with this? We're a bit stuck in T10636. The idea is that we'd like the release process to automatically populate the AppData files' release tags.

Did you ask release-team@ ?
See add-bugzilla-version under sysadmin/release-tools. More details in this old thread:
https://mail.kde.org/pipermail/release-team/2017-July/010474.html

About the other points, it wouldn't be the first time nor the last, where a set of components with different version numbers is distributed together, or where the advertised version or name does not match the internal number. Linux (or other kernel-based) distributions, Hadoop distributions, OpenStack releases, commercial products which aggregates various components, and so on have internal version numbers which do not match the bundle versions (and it happens also for few monolithic products like Microsoft Windows or Microsoft Office).

If we solve the issue with the population of appdata and we add the version of the bundle to the about box, would this be still an issue? As I said, I think that the name of the bundle is a more real problem from a distribution and marketing point of view than the versioning ("KDE Applications is made of KDE applications, but not all of them (?)").

I think this is the wrong mindset, i'd say "KDE Applications doesn't exist", it's just a name we made up because listing the 200 applications we release at the same time in a single headline would not work.

Personally i don't want people thinking they use "KDE Applications", i want them thinking how they just use gwenview or ark or kgpg or spectacle, they just happen to be released at the same time because it's easier for everyone involved.

I think then we'd have to rethink the way we promote, which could also be a solution. I.e. stop having a version number for KDE Applications entirely, instead of having a YY.MM we just make a "KDE updates apps today" announcement on some day, and the announcement includes a full list with individual versions. If we don't want it to be used, why have the number?

In T10755#180944, @aacid wrote:

I think this is the wrong mindset, i'd say "KDE Applications doesn't exist", it's just a name we made up because listing the 200 applications we release at the same time in a single headline would not work.

Personally i don't want people thinking they use "KDE Applications", i want them thinking how they just use gwenview or ark or kgpg or spectacle, they just happen to be released at the same time because it's easier for everyone involved.

In T10755#180945, @hein wrote:

I think then we'd have to rethink the way we promote, which could also be a solution. I.e. stop having a version number for KDE Applications entirely, instead of having a YY.MM we just make a "KDE updates apps today" announcement on some day, and the announcement includes a full list with individual versions. If we don't want it to be used, why have the number?

Yep.

I think fully embracing the "KDE Applications YY.MM" version number makes sense, but ditching it entirely could work too. What I don't think works is doing both and saying, "Here's KDE Applications 19.04, which includes Spectacle 19.04, Gwenview 19.04, and Okular 1.6.7." If I put on my "ordinary user" hat, that's just weird and confusing. I'm using Okular 1.67 from KDE Applications 19.04? What? Which version is it?

Of course ditching the YY.MM versioning system will result in every individual app going back to managing its own version number which is more work for devs and the release team, and paints a picture of a chaotic, uncoordinated process in users' mind. I think there's a lot of value to having one version for the whole bundle.

If we don't want it to be used, why have the number?

Because it's easier to have names for things, so you can call them something. So when we send an email saying let's talk about the feature freeze date or schedule or other stuff people know if we're talking for "this" release or "next" or "next next".

I wouldn't say we don't want it used, it's useful, it's just "KDE Applications" is not one thing, it's lots of things together. It has a name and a version number because it makes talking about it easier, again you can't have a full list on the announcement with 215 names and version numbers, it's just not feasible.

Again you can't have a full list on the announcement with 215 names and version numbers, it's just not feasible.

Sure you can. I don't see a big problem there. The announcement would have a categorized list of app names and versions being released on that day, and before it the usual "highlights in writing" extract.

Also forces us to actually bump those numbers and figure out an efficient means of doing it. There's no reason frameworks can't contain a trivial header-only lib to make version number code in apps consistent and to make sure the bump can be scripted.

What I don't think works is doing both

Yes.

paints a picture of a chaotic, uncoordinated process in users' mind

I don't necessarily think so. It's worth keeping in mind that having a unified version number for "KDE Applications" doesn't end the confusion, and we meet that confusion all the time. KDE still releases other applications with individual version numbers outside of KDE Applications. But very often I hear exchanges like:

A: What version of Krita/Yakuake/etc are you on?
B: YY.MM

... even though they're not released with KDE Applications at all. Unifying the KDE Applications version number won't fix that.

Increasingly I think the only real fix is to go individual-for-all and change the public messaging to be around "Today is KDE apps release day" instead of "Today KDE apps YY.MM is out". This is incidentally what people were talking about doing when the thing was conceived BTW, and I think we're just discovering that we didn't go far enough.

In T10755#180948, @hein wrote:

It's worth keeping in mind that having a unified version number for "KDE Applications" doesn't end the confusion, and we meet that confusion all the time. KDE still releases other applications with individual version numbers outside of KDE Applications. But very often I hear exchanges like:

A: What version of Krita/Yakuake/etc are you on?
B: YY.MM

... even though they're not released with KDE Applications at all. Unifying the KDE Applications version number won't fix that.

No, but on the other hand me this seems like an argument for trying to get all KDE apps into the "KDE Applications" umbrella since apparently the YY.MM numbering system works in users' minds. Is there any reason why Yakuake still uses its own release schedule, in fact? If some apps are holding back because the KDE Applications release schedule doesn't work for them, then maybe that needs to be addressed.

I don't find being part of KDE Applications releases very compelling for many of my apps. The reasons vary - some are alternatives to other apps in the bundle, some don't act in concert with anything else in the bundle, it means sharing attention with many other things (in two ways - public attention, but also dev attention: many things have to be spun up and be ready for release simultaneously, which is inconvenient), it means no ability to set my own schedule. Not getting to set my own version would actually add to that list.

Interestingly, the bundle having a distinct version number is probably part of the deterrent for me. If the thing was about Release Day and excitement for Release Day, I think it'd be more compelling to be (an optional) part of that excitement vs. throwing your app into some sort of bundle.

But anyways, Yakuake is the easy example here. It's unlikely you'll get Krita into Apps YY.MM :). The bundle doesn't scale to all our needs, even if it's very good for many others.

In T10755#180944, @aacid wrote:

Personally i don't want people thinking they use "KDE Applications", i want them thinking how they just use gwenview or ark or kgpg or spectacle, they just happen to be released at the same time because it's easier for everyone involved.

I don’t see a problem in people thinking they use ‘KDE Applications’. I think I use ‘KDE Applications’ (18.12.3). I see the applications as a bundle, and the number as a version number. And I’m always confused about how difficult it is to find out which version of ‘KDE Applications’ I actually use. It’s not in the ‘About’ dialogue of most applications, and it’s not in KInfocenter, the two places I would expect to see it. So I usually end up typing ‘rpm -qi’ on one of the packages and looking in the ‘Version’ field (which on my distro does not show the application version, but the ‘KDE Applications’ version!).

And I don’t see much value in having separate version numbers for each application. OK, so KPat is at version 3.6. What does that tell me? It does’t even tell me which version it actually is at, since it’s been at ‘version 3.6’ for the last eight years (but there have been many bug fixes and translation updates in the meantime). So version ‘3.6’ can mean a number of different versions, each with its own sets of bugs and features. On the other, the fact that it’s part of KDE Applications 18.12.3 tells me quite a bit. It means that it includes all fixes and translation updates for KDE Applications ≤ 18.12.3, and I can compare the release notes between this version and the previous version I had installed to see what new features and bug fixes have been implemented.

So, personally, I would prefer to see the ‘KDE Applications’ version number both in the ‘About’ dialogue and in KInfocenter.

So version ‘3.6’ can mean a number of different versions, each with its own sets of bugs and features.

That could actually be a symptom of the YY.MM stuff being harmful though - because it let KPat get away with not managing its version number correctly.

How about making the about dialog say:

Line 1: <Appname> <Version>
Line 2: Released YYYY.MM

In T10755#180953, @hein wrote:

So version ‘3.6’ can mean a number of different versions, each with its own sets of bugs and features.

That could actually be a symptom of the YY.MM stuff being harmful though - because it let KPat get away with not managing its version number correctly.

How about making the about dialog say:

Line 1: <Appname> <Version>
Line 2: Released YYYY.MM

Yes, it’s KPat that’s not managing its version number correctly (and it’s not alone in doing this). But if all ‘KDE Applications’ applications used the ‘KDE Applications’ version number, KPat wouldn’t have to manage its version number …

In T10755#180953, @hein wrote:

So version ‘3.6’ can mean a number of different versions, each with its own sets of bugs and features.

That could actually be a symptom of the YY.MM stuff being harmful though - because it let KPat get away with not managing its version number correctly.

On the other hand, having the release team take care of all of this stuff automatically and on a predictable schedule is really nice. It frees the developers from having to manage the version number themselves; it just becomes something that's taken care of automatically. For apps with little manpower and mostly community contributions, that's an advantage, because there may not be anyone to manage the version numbers. Spectacle and Gwenview for example are flagship apps that are currently maintainerless and surviving purely by community contributions. If their developers had to manage some aspect of the version numbering again, it probably wouldn't happen because there are no developers available to do this.

But if all ‘KDE Applications’ applications used the ‘KDE Applications’ version number, KPat wouldn’t have to manage its version number …

Sure, but this is moving us in circles. It's OK to be on that side of the argument, but it needs addressing the concerns that have been brought up to advance the convo, not just restating a position :)

On the other hand, having the release team take care of all of this stuff automatically and on a predictable schedule is really nice.

Sure, Release-Team-as-a-Service is one of the main reasons we have the bundle. If you try to characterize the apps in the bundle and what makes them different from e.g. Krita, it's either apps that feel like they're preinstall candidates on mainsteam systems, or are unmaintained/collectively maintained, or just have no community unto their own or need for one.

But bumping version numbers is a technical problem that can have a technical solution. If the Release Team wants to be a more generically useful service, investing R&D time into how to efficiently and generically bump version numbers in our codebases seems smart. It seems odd to make our entire public messaging for app releases hinge on "it's hard to swap a number in a text file", when porting apps to do it in the same way to make it scriptable is inherently a one-time effort. That can't possibly be the main compelling argument for the unified number (and I don't even think it is).

In T10755#180945, @hein wrote:

I think then we'd have to rethink the way we promote, which could also be a solution. I.e. stop having a version number for KDE Applications entirely, instead of having a YY.MM we just make a "KDE updates apps today" announcement on some day, and the announcement includes a full list with individual versions. If we don't want it to be used, why have the number?

"KDE updates apps today" + full list of app versions sounds good to me.

The list can be auto-generated by a script from some standardized CMake variables like PACKAGE_VERSION_{MAJOR,MINOR,MICRO}. For those apps that prefer auto-incremented versions, the script can optionally bump these version numbers (like it is already being done for Kate/Dolphin/etc).

This would result in announcements like this:

KDE Ships %d Updated Applications in 2019 Q2 Release Season

What's News:
 ... some highlights/app picks here ...

Full list of applications released today:
 * Spectacle 19.04
 * Gwenview 19.04
 * Okular 1.6.7

In my opinion the above isn't confusing since we never mention "19.04" outside of the list of individual versions.

We could drop the "2019 Q2" part, but it might be useful to avoid tens of identically titled announcements.

In T10755#180958, @hein wrote:

But bumping version numbers is a technical problem that can have a technical solution.

It's not a problem. we've been doing that for years https://community.kde.org/Guidelines_and_HOWTOs/Application_Versioning

In T10755#180951, @huftis wrote:

So version ‘3.6’ can mean a number of different versions, each with its own sets of bugs and features.

This can be fixed, for example I would suggest these approaches:
A. Forbid reuse of the same version in different KDE Applications releases. If a maintainer didn't update app version since the last release, the release manager contacts him/her and asks to do something (maintainer may then change "3.6" to "3.6.1" or "4.0" or something else). If there is no maintainer, "3.6" becomes KDE_APPLICATIONS_VERSION (e.g. "19.04.0"): let's assume that if there is no maintainer, then nobody cares about versioning either.
B. Similar, but in case of collision and lack of maintainers produce new version by incrementing the patch level digit, e.g. 3.6 -> 3.6.1 -> 3.6.2 -> ...

In T10755#180961, @aacid wrote:

In T10755#180958, @hein wrote:

But bumping version numbers is a technical problem that can have a technical solution.

It's not a problem. we've been doing that for years https://community.kde.org/Guidelines_and_HOWTOs/Application_Versioning

That just seems to describe how you can make your app follow the KDE Apps YY.MM version number, not how Release Team can bump an individual app version number as we were discussing above.

In T10755#180963, @hein wrote:

That just seems to describe how you can make your app follow the KDE Apps YY.MM version number, not how Release Team can bump an individual app version number.

Looks like we have a subtask: Make sure all apps in "KDE Applications" store version numbers in a unified place, even if the version is not being bumped by script.

In T10755#180964, @aspotashev wrote:

In T10755#180963, @hein wrote:

That just seems to describe how you can make your app follow the KDE Apps YY.MM version number, not how Release Team can bump an individual app version number.

Looks like we have a subtask: Make sure all apps in "KDE Applications" store version numbers in a unified place, even if the version is not being bumped by script.

Nailed it.

In T10755#180963, @hein wrote:

In T10755#180961, @aacid wrote:

In T10755#180958, @hein wrote:

But bumping version numbers is a technical problem that can have a technical solution.

It's not a problem. we've been doing that for years https://community.kde.org/Guidelines_and_HOWTOs/Application_Versioning

That just seems to describe how you can make your app follow the KDE Apps YY.MM version number, not how Release Team can bump an individual app version number as we were discussing above.

Sure, why would the release team bump an individual app version if it wants to follow a random scheme?

In T10755#180965, @hein wrote:

In T10755#180964, @aspotashev wrote:

In T10755#180963, @hein wrote:

That just seems to describe how you can make your app follow the KDE Apps YY.MM version number, not how Release Team can bump an individual app version number.

Looks like we have a subtask: Make sure all apps in "KDE Applications" store version numbers in a unified place, even if the version is not being bumped by script.

Nailed it.

I think that's a really bad idea, now you have things go out of sync and people update the version in one place but not in another etc, etc etc

Sure, why would the release team bump an individual app version if it wants to follow a random scheme?

For the same reason the Release Team releases the app instead of an individual person?

I think that's a really bad idea, now you have things go out of sync and people update the version in one place but not in another etc, etc etc

Isn't that just another subtask of "make sure everything uses version info from some central source"? I know Harald had a patch to make the website use AppStream for example.

In T10755#180974, @hein wrote:

Sure, why would the release team bump an individual app version if it wants to follow a random scheme?

For the same reason the Release Team releases the app instead of an individual person?

I personally don't agree "updating version number if you want to keep your own scheme" is a release team responsability, but you do, it's ok to disagree :)

I think that's a really bad idea, now you have things go out of sync and people update the version in one place but not in another etc, etc etc

Isn't that just another subtask of "make sure everything uses version info from some central source"? I know Harald had a patch to make the website use AppStream for example.

Right, we already have a central source then, it's the CMakeLists.txt file.

I thought you meant "creating a repo with all the version numbers", which meant creating a similar problem to the one we have with the website.

So there's subtask extract version information from CMakeLists.txt, which implies a few things:

• going over the applications to check that they actually do set their version in the top-level CMakeLists, as part of the project() command,
• check that tooling uses that version consistently,
• check that the tooling can provide the version information everywhere it's needed.

This kind of rolls into a best-versioning-practices guide for (CMake-build-based software) things under the KDE umbrella. And it will take a bunch of administrative code-work to get there.

I randomly looked at kmplot, which (not pointing fingers; this is just what it does, which doesn't seem to fit very well with any proposed automation or tooling-for-consistency):

• no version in CMakeLists.txt project()
• version held in the application code as a const char*
• version repeated in text in the docbook (along with text saying "Applications 19.04")
• version repeated in text in a manpage

So that's one community-maintained application that would require quite some massaging to get to whatever automated ideal is chosen.

Just a note about the TODO list for $projects:

In T10755#180982, @adridg wrote:

I randomly looked at kmplot, which (not pointing fingers; this is just what it does, which doesn't seem to fit very well with any proposed automation or tooling-for-consistency):

• no version in CMakeLists.txt project()
• version held in the application code as a const char*

Those two points are relevant, but the fix may not require much time.

• version repeated in text in the docbook (along with text saying "Applications 19.04")
• version repeated in text in a manpage

This is intended. The version specified in the documentation is the version of the *last revision* of the documentation, so it's not something that should be automated.

When I started doing Plasma releases it had various version numbers in use in various ways and I just standardised on one number done in one way updated from a release script. I'd be all for KDE Applications doing the same thing. I'd happily help make this happen if there's consensus.

I don't think rediscussing "KDE Applications" brand is too useful, I like the brand, but my suggestion for it would be "KDE Apps Bundle" :)

Rediscussing the name "KDE Applications" makes a lot of sense. Because it is: broken. Very broken. As partially already mentioned above:

• there is application software developed in the KDE community which is not part of the release bundle "KDE Applications" (e.g. https://kde.org/applications/ talks about "The KDE Applications" as well, obvious name clashing)
• there are plugins and libraries released as part of the release bundle "KDE Applications"
• the meta name "KDE Applications" hides what set of stand-alone software is actually released, which each would deserve some release news on its own
• people who still think in "KDE" software product terms confuse "KDE Applications" version with "KDE Plasma" version
• people who still think in "KDE" software product terms miss out that (most) software from the release bundle "KDE Applications" is multi-platform

The release bundle "KDE Applications" is kind of what was left over when people split off KDE Frameworks and Plasma from KDE SC. Those driving that, mainly interested in the new Plasma brand, did not give much thought on that left-over and just picked any first roughly describing generic term. Without any thoughts about purpose and effects.

IMHO "KDE Applications" is a process (as in: organized activity) name, but not an actual product. The main purpose is

• batch processing of the release work, by release managers and packagers
• batch processing by translation teams, which can plan in advance for some bigger work due to aligned string freeze
• ease of inter-product dependency handling, e.g. with plugins, services or libraries

When it comes to the end user, they are facing names like Okular, Dolphin, Kate, KMail, etc. The term "KDE Applications" does not appear in the UI. It is an additional concept which only complicates things for them.

Plasma itself is a product of its own. While it is composed of separate products (plasmashell, kwin, etc), only the combination itself is a usable product that people use as one item and thus also one name, "Plasma". So a unified version number there makes a lot of sense.

Less so with application software or plugins which can be used individually, on different platforms even. People on the app store will search for the application software by the known name. The release bundle itself is only interesting to those involved in the release process.

How about checking with apps maintainers and where there's no objections or agreement switching to kde apps version something like this?
https://phabricator.kde.org/D21091

That's a bad idea.

We already have a way to do it which is using the cmake project so the scripts that create bugzilla versions can detect the version and you can generate an autogenerated version.h file from cmake so you have the file set exactly in one place at the top of your cmake file