The kde-build-metadata data contains the concept of "4" and "5", so this will likely need to be extend to "6", and everything consuming this needs to be adapted.
Description
Description
Comment Actions
With regards to the Dependency information, for the CI scripting at least we'd just need to define some new branch groups and we would be good to go there.
As I was discussing with some folks over dinner last night though, we may need to make some adaptions to the CI tooling to better work in a Gitlab world, which would involve moving away from the concept of branch groups (and therefore involve reworking how the logical-module-structure file works, along with the naming of the dependency-data-* files)
Comment Actions
I'd be supportive of a change to help better support Gitlab CI; I've already been slowly working to split kdesrc-build into a more backend / frontend model already so it would be a good time for it.
Comment Actions
That's awesome to know. Once we've moved code hosting and review to Gitlab we'll likely start looking into CI so will post more about plans here when that starts happening.
Comment Actions
With the introduction of .kde-ci.yml files, the dependency information is now essentially stored within the repositories themselves.
As such, there should be no issue with Qt 4/5/6.
For CI purposes we will define separate "platforms" for each Qt version to ensure we don't get builds mixing between Qt 5/6.