KDE Gear and KF6

[Neal Gompa]

On Tue, Mar 7, 2023 at 5:29 PM Albert Astals Cid <aacid at kde.org> 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 <vkrause at kde.org> 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!