On Tue, Mar 7, 2023 at 5:29 PM Albert Astals Cid <[email protected]> wrote: > > El dimarts, 7 de març de 2023, a les 1:09:39 (CET), Neal Gompa va escriure: > > On Mon, Mar 6, 2023 at 11:06 AM Volker Krause <[email protected]> wrote: > > > Hi, > > > > > > with Plasma switched to KF6, the question what to do for other modules is > > > coming up as well. Manually released modules have various options there I > > > guess, but for everything covered by the KDE Gear release automation we > > > probably want to standardize the process to not break automation too much, > > > regarding branching at least (for the timeline I expect we need more > > > flexibility). > > > > > > I have seen several scenarios mentioned/discussed so far: > > > > > > (1) The switch to 6 happens within one release cycle. That's the easy case > > > and probably has minimal to no impact on release automation. Unlikely to > > > be relevant for 23.08 already, but probably relevant starting from 23.12. > > > > > > (2) Switching needs more than one cycle. This is more likely to be > > > relevant > > > for 23.08 already. > > > > > > (2a) The migration happens in a separate kf6 branch: > > > - 3 concurrent branches > > > + no impact on the release automation > > > + continuous releases for users > > > > > > (2b) The migration happens in the master branch, additional patch releases > > > are made from the last release branch (ie. instead of e.g. 23.08.0 there > > > would be a 23.04.4) > > > + no change to existing branching patterns for developers > > > - more significant change to release automation > > > + continuous releases for users > > > > > > (2c) Migration in master branch, so further releases > > > + no changes to existing branching patterns > > > + presumably minimal impact to release automation > > > - no bugfix releases for users > > > > I think 2b or 2c would make sense, since that would mirror how things > > are being done for kf5 and Plasma/5.27. > > You can not compare Plasma or KDE Frameworks to KDE Gear. > > Plasma and KDE Frameworks are "single products", they need all to be ported at > once and at the same time. > > KDE Gear are independent products that can [mostly] be ported at their own > speed. Also the ratio of developer/line of code is much smaller in general in > KDE Gear. > > For that I don't think the same solution that makes sense for one thing > doesn't necessarily make sense for the other. >
It's only good until experience incoherence catches up for us. Keep in mind that KDE Gear depends on both Qt 5 and KF5 today. Once both of those aren't supported anymore, that's going to be a big problem for KDE Gear. I would say that it makes sense to consider prioritizing those migrations and apps that don't move just get dropped from the release service until they update. We had problems for *years* with apps depending on Qt4+kdelibs4 and later shim libraries until people *finally* gave up on some of those apps. Maybe we should do that from the beginning this time. -- 真実はいつも一つ！/ Always, there's only one truth!
