Merge stable to master vs cherry-picking

[Friedrich W. H. Kossebau]

Am Mittwoch, 8. Dezember 2021, 07:44:32 CET schrieb Ben Cooksley:
> This is why I have been pushing for people to use @stable in their
> .kde-ci.yml files - even for the 'master' branch.
> It is much simpler for people if you can use stable/released dependencies
> when conducting development.

Other than developers the CI though has no issues building all the deps from 
the master branches, right? So I wonder about the relationship here. 

And actually I see a harm if CI does not build master branches against master 
branches of libraries. If there is no testing of new API in the libraries (and 
this means, libraries beyond KF) against consuming products any issues in new 
API added to the libraries might be discovered too late.

If we had endless resources, any product would be built on CI against a set of 
variants of the dependencies, starting with the minimal reuqired versions of 
libraries and then with the latest versions, and then some sensible 
combinations representing what is typical scenario in the real world.
On our CI we only test one variant (per platform). And if we test master 
against master, this tests both the product and the dependency for 
integration.
If we only test master against stable, then the stable of the dependency will 
get tested twice here (as stable against stable also tests the same), but 
nothing will test master. And given master usually sees more changes, it 
should get at least the same coverage.

So please rethink this. Or is there another requirement why the version of a 
dependency developers use locally needs to be the same version as used on CI?

E.g. with KDevelop master, the find_package(LibKompareDiff2 5.0 CONFIG) means 
any version of LibKompareDiff2 from 5.0 to latest should be fine. Developers 
at home can use 5.0, CI can use latest master.

Cheers
Friedrich