Moving KDevelop to Release service coverage?

[Friedrich W. H. Kossebau]

Am Donnerstag, 21. Oktober 2021, 18:57:59 CEST schrieb Friedrich W. H. 
Kossebau:
> Am Donnerstag, 21. Oktober 2021, 09:37:51 CEST schrieb Milian Wolff:
> > On Mittwoch, 20. Oktober 2021 20:22:55 CEST Friedrich W. H. Kossebau 
wrote:
> > > Disadvantage:
> > > The awkward release-service-oriented branch names and version numbers. I
> > > would propose to use the 5.6.xyz (with xzy generated from the release
> > > service data) approach here, so the major and minor number is still
> > > under
> > > KDevelop control and to match whatever semantics it has, while the patch
> > > level is based on the Release service number.
> > 
> > We could also bump the version numbers to be in line with the other KDE
> > gear applciations, if that's needed. But I have to admit that I don't
> > really know what exactly you are talking about here - can you give a more
> > concrete example? We already use 5.6.xyz after all the way I see it?
> 
> Release service scripts hook into the sources to optionally provide version
> numbers by changing in the toplevel CMakeLists.txt file these lines if
> present:
> --- 8< ---
> set (RELEASE_SERVICE_VERSION_MAJOR "21")
> set (RELEASE_SERVICE_VERSION_MINOR "08")
> set (RELEASE_SERVICE_VERSION_MICRO "2")
> --- 8< ---
> 
> Applications can then use these variables to calculate their version number:
> e.g. by mapping it 1:1 (example Kate, KDE Gear 21.12.0 -> Kate 21.12.0) ---
> 8< ---
> set(RELEASE_SERVICE_VERSION "${RELEASE_SERVICE_VERSION_MAJOR}.$
> {RELEASE_SERVICE_VERSION_MINOR}.${RELEASE_SERVICE_VERSION_MICRO}")
> project(kate VERSION ${RELEASE_SERVICE_VERSION})
> --- 8< ---
> or using those numbers to calculate an ever-increasing patch-level number
> (example Konversation, KDE Gear 21.12.0 -> Konversation 1.8.21120):
> --- 8< ---
> set (RELEASE_SERVICE_COMPACT_VERSION "${RELEASE_SERVICE_VERSION_MAJOR}$
> {RELEASE_SERVICE_VERSION_MINOR}${RELEASE_SERVICE_VERSION_MICRO}")
> 
> # Bump KONVERSATION_BASE_VERSION once new features are added
> set(KONVERSATION_BASE_VERSION "1.8")
> set(KONVERSATION_VERSION "${KONVERSATION_BASE_VERSION}.$
> {RELEASE_SERVICE_COMPACT_VERSION}")
> --- 8< ---
> or do someething else or just ignore it and manually maintain an own scheme.
> 
> The branch names created by the Release service though will always be named
> "release/yy.mm", matching the year quarter cycle.
> 
> For other version numbers like SO version numbers Release service provides
> nothing, that is left to projects.
> 
> Back to KDevelop:
> Given KDevelop has public API for plugins, there needs to be some sense in
> the version number pointing to ABI/API compatibility. The yy.mm.p would be
> hard to use here at least with the capabilities of cmake, which relies on
> the semantic versioning scheme to compare version compatibility.
> And when we agree that KDevelop should continue promoting its plugin
> feature, 3rd-party projects need a sane way to check which API version they
> are building against.
> That is why I suggest to have KDevelop define the major & minor parts of the
> version itself as before, increasing the minor on API breakages and the
> major on big changes (like 5->6 for Qt6 port). While incrementing the patch
> level by deriving from the release service numbers.
> 
> So KDevelop's toplevel CMakeLists would do this to define the version:
> --- 8< ---
> set (RELEASE_SERVICE_VERSION_MAJOR "21")
> set (RELEASE_SERVICE_VERSION_MINOR "12")
> set (RELEASE_SERVICE_VERSION_MICRO "0")
> 
> set (RELEASE_SERVICE_COMPACT_VERSION "${RELEASE_SERVICE_VERSION_MAJOR}$
> {RELEASE_SERVICE_VERSION_MINOR}${RELEASE_SERVICE_VERSION_MICRO}")
> 
> project(KDevelop VERSION "5.7.${RELEASE_SERVICE_COMPACT_VERSION}")
> --- 8< ---
> That way things are automated and no one needs to stand by every release
> time. One catch though: given every quarter the master branch is branched
> into a new stable branch, if someone does an ABI breakage in the master
> branch they also need to remember to bump the minor version if not done
> since the last branching, as well as the KDEVELOP_SOVERSION and the
> KDEV_PLUGIN_VERSION. Can we expect us to manage to care for that?
> 
> Side comment: the latter two could be calculated from the major & minor
> version, and perhaps KDEV_PLUGIN_VERSION even be changed to be the
> KDEVELOP_SOVERSION? What is the offset for KDEV_PLUGIN_VERSION, and would
> there be any reason for bumping it differently from KDEVELOP_SOVERSION?
> 
> To help people who want map KDE Gear version to the KDevelop version they
> are using, the KDE Gear number could be given in brackets after the app
> version (e.g. PIM apps do that, KMail as "Version 5.18.2 (21.08.2)").

Patches to show what this could look like now up as drafts:
* https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/269
* https://invent.kde.org/kdevelop/kdev-python/-/merge_requests/13
* https://invent.kde.org/kdevelop/kdev-php/-/merge_requests/4

Cheers
Friedrich