I'm afraid someone's currently doing a suboptimal job at this. After the 5.7.1 release, I noticed that 5.7.1 was added to "kmail" (sic!) in Bugzilla, but not to "kmail2". Now I think that some more products should have been equipped with 5.7.1, too.

This time, 5.7.3 (sic!) should have been 5.7.2 instead, but was incorrectly added to

• syndication: its only other version starting with "5." is "5.7.1". Are the others missing? Or should we stop adding versions to it? Or are those missing versions correct?
• kcalcore, kcalutils, kcontacts, kholidays, kimap, kmailtransport, kmbox, kmime, ktnef: same as syndication, but with extra versions "5.6.1" and "5.6.4x". Even if there is no ktnef-5.x.x before 5.6.1, why are 5.6.2 and 5.6.3 and 5.7.0 missing?
• knotes: only other kf5-based version is 5.7.1, which seems wrong, too
• kmail (sic!)
• akregator, Akonadi, kaddressbook, kontact, korganizer: versions before 5.7.2 were added correctly

Otoh, 5.7.2 (nor, correctly, 5.7.3) was not added to

• korgac: 5.7.1 is missing, too
• kdepim: although there is 5.7.0 and before; 5.7.1 is (correctly?) missing, too
• kmail2: similar to the 5.7.1 release

Has this been automated? If so, we need to adjust that.

In any case, is there any point in adding intermediate, missing versions, like 5.6.3 for kcalcore, kcalutils, ...?

I removed 5.7.3 (where applicable) and added 5.7.2 (where sensible) for: Akonadi, akregator, kaddressbook, kcalcore, kcalutils, kcontacts, kholidays, kimap, kmail, kmail2, kmailtransport, kmbox, kmime, knotes, kontact, korgac (added 5.7.1, too), korganizer, ktnef, syndication.

By the way: is there any authoritative list of PIM products (that should have a Bugzilla product?), and an authoritative list of their versions? For the latter, I'd go for git tags, I guess?

An authoritative list is here: https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects/kde/pim - each folder is a configuration for a PIM repo, all PIM repos a under kde/pim module in the repo hierarchy. The latest version can be deduced from tags indeed. There is still a disjoint between the internal PIM versioning (5.x.y) and the official KDE Applications versioning (YY.MM) and it's somewhat unclear what we should be putting into the Bugzilla versions etc. @mlaurent opinions?

Hi,
aboutdata gives us 5.x.y => we need to us it for bugzilla.

And we have it at the moment in bugzilla so we can continue with it :)

After that I don't know why it's not updated as I added version in all CMakeLists.txt as requested:

We need to use project version for bugzilla.

"
set(PIM_VERSION "5.7.40")
project(AkonadiSearch VERSION ${PIM_VERSION})
"
so I don't know why it was not updated.

The problem of kmail being equipped with new versions automatically instead of kmail2... would that have to do with the fact that it is "kmail" in the repo-metadata repo?

Also, I came across the mail below on plasma-devel, which details a policy to close old versions for bug reporting in Bugzilla. The policy also seems to govern which versions are added to Bugzilla in the first place (e.g., what about those 5.6.40 versions, although no other x.y.40 versions have been added before?)

Given that kmail2-4.11.5 and many other very old versions are still active in Bugzilla, there is currently no such policy for PIM. My questions: should there be one, and is this the right place to discuss it? A policy for PIM would have to be adapted, since we do not have LTS versions and we cannot require all distributions to always ship the most recent versions only.

I'd gladly disable all those old versions, but I don't know where to stop. Noone objected when I closed all those 4.x and 5.0 bugs, so I guess disabling <5.1 is OK? What about, say, 5.4.x?

The email in question:

Am 2018-02-01 22:19, schrieb David Edmundson:

In bugzilla a product can be "Open for bug entry" or not.
It can also be done at a per-version level.

When unset a user will not see it in the "enter bug" list, or the
version won't be listed. If they force it, they'll get a message like:
https://bugs.kde.org/enter_bug.cgi?product=Aktion

Currently Plasma 4 is "open for bug entry".

One can also enter a bug on the 4.x entries on products like
systemsettings, kscreenlocker etc.

kscreenlocker is still a product in 5.

Should we disable them? It still gets a few every month and it's
wasting the user's time if we're clearly not going to do anything with
it.

+1

FWIW: I've already disabled new bugs on plasmashell 5.0 -> 5.7, I know
Martin does the same in kwin

I'm even more strict. For KWin the following rules are applied:

• latest two minor version of current release (e.g. currently 5.11.5 and 5.11.4)
• latest two minor version of current LTS release (e.g. currently 5.8.7 and 5.8.8)
• latest development release
• master
  
  The main thinking is: I'm not interested in triaging bugs for 5.10, we won't do fixes any more. Neither am I interested in bugs for 5.11.3 -> distros should update.
  
  So next week this will change to:
• 5.11.95 will be disabled
• 5.8.x will be disabled
• 5.11.4 will be disabled
  
  If we apply that rule for more prodcuts, it would be super awesome to automate. I just noticed that all 5.11 versions were still open for bugs.
  
  Cheers Martin

5.7.3 versions are currently missing in the bug tracker

@tillschafer approached me today: He wanted to report a bug for kmail2-5.8.2, but the version was missing. I added that version for all PIM products (I could think of [1]), and additionally a mix of versions 5.7.0, 5.7.2, 5.7.3, 5.8.0 and 5.8.1 for each product. Someone added some versions for some products, but not systematically at all. Some had 5.7.1, 5.7.3 and 5.8.1 set, while others had 5.7.0, 5.7.1, 5.7.2 and 5.8.1, and so on.

On the other hand, someone added kmail (not kmail2) version 5.8.1.

Is anyone working on this? [2] Is there any way those versions could automatically be added to bugzilla?

Also, I get that noone will actively and openly support my suggestion to deactivate older versions that are no longer supported anyway, as described in my comment on Feb 13, 18. Instead, I now offer to do at least the initial deactivation work by shutting off all versions older than 5.7.3 (distros should at least offer the latest patch level of older releases). Of course, I won't do it unannounced, so here is the final call for opposition to this. If you feel the urge to oppose, remember that deactivating a version only prevents users from reporting new bugs against those versions; it does not close existing bugs. Otherwise, feel free to speak up. I cannot think of user or dev groups with a dire need to report bugs for old versions, but if you, dear reader, know a use case or users/devs who might think otherwise, feel free to inform them about my plans to break their workflow/business/whatever.

I cannot promise that I'll be able to keep up with shutting down versions that become too old. However, I don't think that the initial step would harm in that case.

Finally, a clear statement someplace official about supported versions would be really, really nice. At the least, we could state in some *.k.o wiki (userbase?) that KDE PIM versions other than the latest y release (in a 5.y.z scheme) and the latest z release of the next older y, is not currently supported by anyone we know of, and definitely not by any regular contributor. This would align nicely with the shutting down of old versions in bugzilla. Would anyone oppose that? Again, who's to be CC'd about such a move? Any other suggestions on this?

And just so that anyone knows that I didn't change my mind: KDE PIM 5.y.z versioning instead of KDE Apps yy.mm.z versioning adds confusion, but still no advantage :-P

[1] Akonadi, akregator, kaddressbook, kidentitymanagement, kmail2, kmailtransport, kontact, kontactinterface, korgac, korganizer, kpimtextedit
[2] Maybe someone who would brag about their maintainership without hesitation?

Added 5.8.3 to the [1] products from my last comment by hand; deactivated all versions of those products that are not 5.7.3, 5.8.3, git, unspecified or enterprise.

It's that time of the year again: Why does KDE PIM have its own versioning scheme? We know there are reasons to just stick to the KDE Applications versioning scheme, but to this day, no one gave a reason not to.

Why I bring this up again, you ask? Well, a user tried to get some help via the mailing list, but was very confused by our version numbers:

Debian calls that version "4:18.08.1-1", which I'm guessing the the version
number of the KDE release, rather than KMail in particular. I tried to find
the KMail version using [this list](https://www.kde.org/info/
applications-18.08.1.php), but it just said 18.08.1.

And he's not the only one, because I am still constantly confused, too.

If the reason is some involved porting of release scripts, CMakeLists.txt and such, I gladly offer my help; maybe we can also resolve this very task in the process. I just had to add 5.9.2 manually to b.k.o again.

And in case you're wondering: no one complained to me so far after I deactivated all those old versions in b.k.o, so we might want to add disabling of old versions to the automation.