From kde-release-team  Thu Mar 09 16:33:09 2023
From: Volker Krause <vkrause () kde ! org>
Date: Thu, 09 Mar 2023 16:33:09 +0000
To: kde-release-team
Subject: Re: KDE Gear and KF6
Message-Id: <3236807.44csPzL39Z () vkpc5>
X-MARC-Message: https://marc.info/?l=kde-release-team&m=167837962104511
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart8202567.T7Z3S40VBb"

--nextPart8202567.T7Z3S40VBb
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

On Tuesday, 7 March 2023 01:05:50 CET Albert Astals Cid wrote:
> El dilluns, 6 de mar=E7 de 2023, a les 17:04:12 (CET), Volker Krause va
>=20
> escriure:
> > Hi,
> >=20
> > 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 mu=
ch,
> > regarding branching at least (for the timeline I expect we need more
> > flexibility).
> >=20
> > I have seen several scenarios mentioned/discussed so far:
> >=20
> > (1) The switch to 6 happens within one release cycle. That's the easy c=
ase
> > 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.
>=20
> I don't think this is feasible, we had years of kdelibs4+KF5 releases for
> KDE Applications.

Right, certainly not for all of Gear at once! For individual smaller module=
s I=20
do think completing the switch within one cycle is definitely feasible thou=
gh,=20
especially when starting from an already existing dual-version state.=20
Basically option 2a with an extremely short lived kf6 branch.

> > (2) Switching needs more than one cycle. This is more likely to be
> > relevant
> > for 23.08 already.
> >=20
> > (2a) The migration happens in a separate kf6 branch:
> > - 3 concurrent branches
> > + no impact on the release automation
> > + continuous releases for users
> >=20
> > (2b) The migration happens in the master branch, additional patch relea=
ses
> > 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
> >=20
> > (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
> >=20
> > What are your thoughts on this?
>=20
> I think 2a worked well on the kf5 migration and should serve us well here
> too.

Leaving aside the orthogonal discussion on whether/when to drop things from=
=20
Gear, it seems that is the way to go then.

Thanks,
Volker

--nextPart8202567.T7Z3S40VBb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQQAnu3FVHA48KjZ07R/lszWTRLSRwUCZAoKRQAKCRB/lszWTRLS
R44zAKCtF7AY9MLaUwD2/zZsb2f0bbK4OgCfcKQ85UmT/O/ewjjpiYWgT1a4wGY=
=Wh3T
-----END PGP SIGNATURE-----

--nextPart8202567.T7Z3S40VBb--