KDE Gear and KF6

[Albert Astals Cid]

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.

Cheers,
  Albert

> 
> The transition to Qt6 isn't expected to be as painful as the Qt5
> transition was, and cutting over to Qt6 in mainline branches sooner
> rather than later would be good so applications can stop relying on
> the KDE Qt5 thing we have right now.