<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 8, 2021 at 10:38 PM Friedrich W. H. Kossebau <<a href="mailto:kossebau@kde.org">kossebau@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am Mittwoch, 8. Dezember 2021, 07:44:32 CET schrieb Ben Cooksley:<br>
> This is why I have been pushing for people to use @stable in their<br>
> .kde-ci.yml files - even for the 'master' branch.<br>
> It is much simpler for people if you can use stable/released dependencies<br>
> when conducting development.<br>
<br>
Other than developers the CI though has no issues building all the deps from <br>
the master branches, right? So I wonder about the relationship here. <br></blockquote><div><br></div><div>The relationship is that developers may accidentally end up using new API or other functionality that only exists in current master.</div><div>That prevents people from using distribution packagers to develop on our software, and increases the barrier to entry.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
And actually I see a harm if CI does not build master branches against master <br>
branches of libraries. If there is no testing of new API in the libraries (and <br>
this means, libraries beyond KF) against consuming products any issues in new <br>
API added to the libraries might be discovered too late.<br></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">The CI system is limited to testing two things:</div><div class="gmail_quote">1) That it compiles and installs successfully</div><div class="gmail_quote">2) That the tests execute successfully</div><div class="gmail_quote"><br></div><div class="gmail_quote">While good things, they are no substitute for the software being run by a developer and actually tested. That requires developers that run master for everything.</div><div class="gmail_quote">There is already a number that do that - however it shouldn't stop newcomers from being able to develop using stable if that is reasonable to do so.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">With regards to things within the same release unit, those should be using @same not @stable - so those can still use the "latest" API where needed.</div><div class="gmail_quote">The barrier to entry for those however (except for areas like PIM that have a colossal dependency tree) should be relatively small - usually just one or two other projects that need to be built.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If we had endless resources, any product would be built on CI against a set of <br>
variants of the dependencies, starting with the minimal reuqired versions of <br>
libraries and then with the latest versions, and then some sensible <br>
combinations representing what is typical scenario in the real world.<br>
On our CI we only test one variant (per platform). And if we test master <br>
against master, this tests both the product and the dependency for <br>
integration.<br>
If we only test master against stable, then the stable of the dependency will <br>
get tested twice here (as stable against stable also tests the same), but <br>
nothing will test master. And given master usually sees more changes, it <br>
should get at least the same coverage.<br>
<br>
So please rethink this. Or is there another requirement why the version of a <br>
dependency developers use locally needs to be the same version as used on CI?<br></blockquote><div><br></div><div>What developers use is of little concern to the CI system.</div><div><br></div><div>The CI system however keeps watch over the buildability of our software, and currently when it comes to testing whether minimum versions work does a very minimal job of doing so.</div><div>I would like to see that improved, to ensure we do not accidentally introduce barriers to entry that should not exist.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
E.g. with KDevelop master, the find_package(LibKompareDiff2 5.0 CONFIG) means <br>
any version of LibKompareDiff2 from 5.0 to latest should be fine. Developers <br>
at home can use 5.0, CI can use latest master.<br></blockquote><div><br></div><div>CI should be using 5.0 - otherwise nobody is checking that newcomers can use 5.0.</div><div>Experience has shown that maintainers/day to day developers do use master and then go ahead and add dependencies on versions that are newer without realising it - until someone comes along with a build that fails mid way through because the version of $kdeLibrary they have is actually too old.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers<br>
Friedrich<br>
<br></blockquote><div><br></div><div>Cheers,</div><div>Ben</div><div><br></div></div></div>