El dilluns, 22 de desembre del 2025, a les 23:45:54 (Hora estàndard d’Europa central), Neal Gompa va escriure: > On Mon, Dec 22, 2025 at 5:23 PM Albert Astals Cid <[email protected]> wrote: > > El dijous, 18 de desembre del 2025, a les 11:11:29 (Hora estàndard > > d’Europa > > > > central), Neal Gompa va escriure: > > > On Mon, Dec 15, 2025 at 3:40 AM Albert Astals Cid <[email protected]> wrote: > > > > I would like to propose this minimum cmake version policy for KDE > > > > Frameworks.> > > > > The required minimum cmake version for KDE Frameworks will be the > > > > maximum > > > > of: > > > > * The required cmake version of required Qt at that time > > > > * The cmake version released 1 year before the required Qt at that > > > > time > > > > > > > > Let's do the calculations for now. > > > > > > > > required Qt at the time = 6.8 > > > > required cmake version of Qt 6.8 = 3.16 > > > > Qt 6.8 release date = 8 October 2024 > > > > 1 year before Qt 6.8 relase date = 8 October 2023 > > > > > > > > cmake 3.27.0 release date = 18 July 2023 > > > > cmake 3.28.0 release date = 6 December 2023 > > > > > > > > cmake version released 1 year before the required Qt at that time = > > > > 3.27 > > > > > > > > So this policy would suggest to increase our minimum cmake requirement > > > > to > > > > max(3.27, 3.16) -> 3.27 > > > > > > > > This ties updating the minimum cmake version to when we update Qt > > > > which i > > > > think makes sense, if we are going to as people to update Qt, we may > > > > as > > > > well ask them to update cmake (which is in my opinion much easier) > > > > > > > > I know it is quite a jump in minimum required cmake version but i > > > > think > > > > having a policy is much simpler than having to justify every time we > > > > want > > > > to do an update. > > > > > > > > What do you all think? > > > > > > I think it's reasonably sensible. > > > > > > However, I'm going to ask for the caveat that we don't go up to > > > requiring CMake 4.x for the time being. > > > > Requiring CMake 4.x will only happen as per the rules when we depend on a > > Qt 6 released later than March 28 2026 (possibly Qt 6.11 if the schedule > > does not slip), which means it will not happen until Qt 6.13 is released, > > which more than a year away. > > > > Hopefully all the cmake 4 woes will be solved by then? > > At the rate things are going, I don't think that's going to happen. > It's been painful enough in Fedora preparing to upgrade, and I foresee > other distributions struggling even harder with it than we are.
Ok, what about adding a new clause A) The required cmake version of required Qt at that time B) The cmake version released 1 year before the required Qt at that time C) Updating major cmake versions should be discussed in the mailing list and not done automatically because of point B) of this policy Cheers, Albert
