T10755: Unifying Applications' release versions
Adriaan de Groot <[email protected]>
| Newsgroups | gmane.comp.kde.devel.pim,gmane.comp.kde.devel.utils,gmane.comp.kde.devel.games,gmane.comp.kde.devel.konsole,gmane.comp.kde.devel.kfm |
|---|---|
| Message-ID | <[email protected]> |
adridg added a comment. 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. TASK DETAIL https://phabricator.kde.org/T10755 To: ngraham, adridg Cc: adridg, heikobecker, aspotashev, huftis, cullmann, hein, ltoscano, kde-utils-devel, #kde_games, #kde_pim, sitter, jriddell, #spectacle, #gwenview, #konsole, #kate, #dolphin, aacid, cfeck, #kde_applications, ngraham