After bug #335328 and bug #335517, I decided not to report each of such missing version numbers separately, but instead collect them in one bug report (this one). In the first place, I tried to fully automate those checks, but it turns out that this is not trivial and takes a lot of time. Hence, I started with checking all games from kicker manually. Here are my observations: just missing versions in bug tracker * granatier 1.2.1 * kajongg 4.13.0 * kbreakout 1.1.0 * kollision 0.1 * palapeli 2.0 * knetwalk 3.2.0 There are some version numbers with a different format in the application (KAboutData(…)) than in the bug tracker. For example lskat reports as v1.40, and the bug tracker shows 1.40 without the leading 'v'. Still, when invoking the wizard for reporting a bug against lskat, the version number is mapped correctly and 1.40 is preselected. For other applications, this does not work. version numbers known, but not automatically recognized: * kfourinline v1.40 * amor 2.4.0 * kmines 3.0 (02 Aug 2007) and there are some other thins as well: * kshisen uses more sophisticated version numbers, currently "Version 1.8+ #13", not sure how to deal with that * pairseditor yields "Sorry, either the product pairseditor does not exist or you aren't authorized to enter a bug into it". There is a product named "pairs" in the bug tracker with "editor" as component, but pairseditor reports a different version number than pairs.
Some more: missing versions in bug tracker * okteta 0.13.1 * kalarm 2.10.9-ak * ktnef 4.13.1 <-- reports KDEPIM_VERSION as own version * kgpg 2.12.1 * klinkstatus 0.7.1 * cervisia 3.10.0 * kopete 1.6.60 * kig v1.0 (no version except "unspecified" available so far) * rocs 1.11.0 * parley 1.0.0 * artikulate 0.3.1 sophisticated version number * konverstaion 1.5-master #4303 bugs.kde.org says that product does not exist * contactthemeeditor * importwizard * akonadiconsole (but there is such a component in product akonadi) Some applications are part of a product as a component, but their version number differs from the product. I have no idea what to do with them, but now that I have collected a small list of then, I add them here * kdeui v1.0.1, part of kdelibs * krandrtray 0.5, part of krandr * kwrite 4.13.1, uses KDE_VERSION_STRING as version number, is part of kate
* knode 4.13.2
* granatier 1.2.1 added * kajongg 4.13.0 added * kbreakout 1.1.0 added * kollision 0.1 added * palapeli 2.0 added * knetwalk 3.2.0 added * kshisen 1.8+ #13 added * knode now at 4.13 Pre * Konversation now at 1.5.1
Dolphin now is 14.12.3 (using KDE DP 4.14.6) so I can't correctly describe a but because latest version in the DB is the 4.14.3 (https://bugs.kde.org/show_bug.cgi?id=345853)
*** Bug 351249 has been marked as a duplicate of this bug. ***
*** Bug 352798 has been marked as a duplicate of this bug. ***
List of products: * Akonadi * akregator * kdepim * kmail2 * kontact * korgac * korganizer List of versions * 5.1 * 5.1.1 * 5.1.2 * 5.1.3 * 5.2.0 * 5.2.1 * 5.2.2 * 5.2.3 * 5.3.0 * 5.3.1 All of the products above should have all the versions above. Because of the next paragraph, we would also need korganizer-5.0. Some wrong versions appear as well in the version dropdowns, so bugs should be moved as follows: Akonadi-15.12 -> Akonadi-5.1 Akonadi-16.04 -> Akonadi-5.2.0 korganizer-15.08.0 -> korganizer-5.0 korganizer-15.12.2 -> korganizer-5.1.2 Of course, I could do this "move" part as well, after the the appropriate versions have been added, and then report back. After these moves, the following versions can be removed: Akonadi 15.12 and 16.04 korgac 15.08.0 korganizer 15.08.0 and 15.12.2
(In reply to Denis Kurz from comment #7) > List of products: > * Akonadi > * akregator > * kdepim > * kmail2 > * kontact > * korgac > * korganizer > > List of versions > * 5.1 > * 5.1.1 > * 5.1.2 > * 5.1.3 > * 5.2.0 > * 5.2.1 > * 5.2.2 > * 5.2.3 > * 5.3.0 > * 5.3.1 > Their versioning seems to be mixed. The repository tags do align with the applications version scheme, e.g. https://quickgit.kde.org/?p=akonadi.git However, akonadictl -v gives me the 5.x.y scheme.
frameworks kio: https://phabricator.kde.org/T3747
Since the PIM guys seem to be determined to stick to their internal version numbers, can we agree for the moment on versions like "5.3.0 (KDE Applications 16.08.0)"? I learned in #kde-sysadmin that admins have the option to rename existing versions. That would also be helpful for KOrganizer and Akonadi, for example to rename KOrganizer "15.08.0" to "5.0 (KDE Applications 15.08.0)". If we agree on this (interim?) solution, I would compile a list of version translations for Akonadi and Korganizer, and a new list of requested versions.
The list of versions mentioned in comment 10: * 5.1 (KDE Applications 15.12.0) * 5.1.1 (KDE Applications 15.12.1) * 5.1.2 (KDE Applications 15.12.2) * 5.1.3 (KDE Applications 15.12.3) * 5.2.0 (KDE Applications 16.04.0) * 5.2.1 (KDE Applications 16.04.1) * 5.2.2 (KDE Applications 16.04.2) * 5.2.3 (KDE Applications 16.04.3) * 5.3.0 (KDE Applications 16.08.0) * 5.3.1 (KDE Applications 16.08.1) And we would need these renames: Akonadi: * 15.12 -> 5.1 (KDE Applications 15.12.0) * 16.04 -> 5.2.0 (KDE Applications 16.04.0) korganizer * 15.08.0 -> 5.0 (KDE Applications 15.08.0) * 15.12.2 -> 5.1.2 (KDE Applications 15.12.2)
Done. Next time, please open a new bug report instead of hijacking an unrelated one.
(In reply to Christophe Giboudeaux from comment #12) > Done. Next time, please open a new bug report instead of hijacking an > unrelated one. Although i was not directly addressed: thought this is a accumulative bug reports for all kinds of missing versions? Should we go back to assigned in this case?
I prefer several bug reports instead of piling everything in one. example : before adding the pim versions, I spend some time checking the reported missing versions in the other comments. These were all added by someone else. I could have spent this time elsewhere :) Once a "bugs.kde.org / product/component change" is fixed, please open a new one for the next request.