Re: kio-extras and the KF5/KF6 period
Am Dienstag, 20. Juni 2023, 14:52:44 CEST schrieb David Redondo: > Harald and I prototyped another solution to build a Qt > 5 and Qt 6 version out of the same repo and employed it on > plasma-integration: https://invent.kde.org/plasma/plasma-integration/-/ > merge_requests/91 > This has the advantage of having the code for both versions in > the same place and the Qt5 version being not stuck on some old > version. Also the translations can be shared automatically since > they use the same catalog. > There is one case where Qt uses unversioned targets and one > unversioned ecm variable but cadavidn be easily worked around. And here is the same idea applied to building both Qt5 and Qt6 versions out of a single src directory at the same time. The repo is smaller and nothing duplicated so you can get a better idea of what's going on. This looks like a good option for me for repos with little divergence between both versions. https://invent.kde.org/plasma/kwayland-integration/-/merge_requests/45 David
Re: kio-extras and the KF5/KF6 period
Am Dienstag, 20. Juni 2023, 14:52:44 CEST schrieb David Redondo: > Harald and I prototyped another solution to build a Qt > 5 and Qt 6 version out of the same repo and employed it on > plasma-integration: https://invent.kde.org/plasma/plasma-integration/-/ > merge_requests/91 > This has the advantage of having the code for both versions in > the same place and the Qt5 version being not stuck on some old > version. Also the translations can be shared automatically since > they use the same catalog. > There is one case where Qt uses unversioned targets and one > unversioned ecm variable but cadavidn be easily worked around. And here is the same idea applied to building both Qt5 and Qt6 versions out of a single src directory at the same time. The repo is smaller and nothing duplicated so you can get a better idea of what's going on. This looks like a good option for me for repos with little divergence between both versions. https://invent.kde.org/plasma/kwayland-integration/-/merge_requests/45 David
Re: kio-extras and the KF5/KF6 period
Am Mittwoch, 21. Juni 2023, 12:31:47 CEST schrieb Ben Cooksley: > It sounds like we are approaching (or have already hit) a "crossroads" > where it is time for the Qt 5 codebase to enter a stable release only > phase, with master becoming Qt 6 exclusive. > Splitting the code into separate Qt 5 / Qt 6 folders sounds like it will be > difficult to ensure that all bug fixes are applied equally to both sides. You are right, that's why in general for Plasma projects the master branch is Qt6 only. But for some special projects we need to have Qt 5 AND Qt 6 builds in a Plasma 6 session to support Qt5 apps on Plasma 6 - for example Breeze or plasma- integration (our QPlatformTheme). Freezing Qt5 at a stable version doesn't work quite here as development happening on master will lead to UX and visual divergence compared to the frozen branch. > Cheers, > Ben David
Re: kio-extras and the KF5/KF6 period
On Wed, Jun 21, 2023 at 8:22 PM Harald Sitter wrote: > On Tue, Jun 20, 2023 at 11:23 PM Sune Vuorela wrote: > > > > On 2023-06-20, David Redondo wrote: > > > Harald and I prototyped another solution to build a Qt > > > 5 and Qt 6 version out of the same repo and employed it on > > > plasma-integration: > https://invent.kde.org/plasma/plasma-integration/-/ > > > merge_requests/91 > > > > Did I miss something or is this just branching but without having git to > > help us move stuff between versions? > > Yes but no. If we have two branches we also need two tars and everyone > needs to do two things. If we have everything in the same branch then > everything is as usual. Also, the sources are so divergent that > picking is bound to be annoying. > It sounds like we are approaching (or have already hit) a "crossroads" where it is time for the Qt 5 codebase to enter a stable release only phase, with master becoming Qt 6 exclusive. Splitting the code into separate Qt 5 / Qt 6 folders sounds like it will be difficult to ensure that all bug fixes are applied equally to both sides. > > HS > Cheers, Ben
Re: kio-extras and the KF5/KF6 period
On Tue, Jun 20, 2023 at 11:23 PM Sune Vuorela wrote: > > On 2023-06-20, David Redondo wrote: > > Harald and I prototyped another solution to build a Qt > > 5 and Qt 6 version out of the same repo and employed it on > > plasma-integration: https://invent.kde.org/plasma/plasma-integration/-/ > > merge_requests/91 > > Did I miss something or is this just branching but without having git to > help us move stuff between versions? Yes but no. If we have two branches we also need two tars and everyone needs to do two things. If we have everything in the same branch then everything is as usual. Also, the sources are so divergent that picking is bound to be annoying. HS
Re: kio-extras and the KF5/KF6 period
Am Mittwoch, 17. Mai 2023, 00:02:18 CEST schrieb Albert Astals Cid: > kio-extras provides plugins for kio. > > So KF5 applications want a KF5 kio-extras and KF6 applications want a KF6 > kio- extras. > > If we're going to support a period on which we ship both Kf5 and KF6 based > applications we need to: > > Make sure kf5 and kf6 are coinstallable. > > a) release two tarballs, one for each KF > b) release one tarball that compiles both for kf5 and kf6 > c) just release the kf6 tarball, stop releasing the kf5 tarball but ask > distributions to still install it > > Harald and I prototyped another solution to build a Qt 5 and Qt 6 version out of the same repo and employed it on plasma-integration: https://invent.kde.org/plasma/plasma-integration/-/ merge_requests/91 This has the advantage of having the code for both versions in the same place and the Qt5 version being not stuck on some old version. Also the translations can be shared automatically since they use the same catalog. There is one case where Qt uses unversioned targets and one unversioned ecm variable but cadavidn be easily worked around. David
Re: kio-extras and the KF5/KF6 period
On Tue, Jun 20, 2023 at 3:46 PM Luigi Toscano wrote: > > Harald Sitter ha scritto: > > On Tue, Jun 20, 2023 at 2:58 PM Luigi Toscano > > wrote: > >> > >> David Redondo ha scritto: > >>> Am Mittwoch, 17. Mai 2023, 00:02:18 CEST schrieb Albert Astals Cid: > kio-extras provides plugins for kio. > > So KF5 applications want a KF5 kio-extras and KF6 applications want a KF6 > kio- extras. > > If we're going to support a period on which we ship both Kf5 and KF6 > based > applications we need to: > > Make sure kf5 and kf6 are coinstallable. > > a) release two tarballs, one for each KF > b) release one tarball that compiles both for kf5 and kf6 > c) just release the kf6 tarball, stop releasing the kf5 tarball but ask > distributions to still install it > > > >>> > >>> Harald and I prototyped another solution to build a Qt > >>> 5 and Qt 6 version out of the same repo and employed it on > >>> plasma-integration: https://invent.kde.org/plasma/plasma-integration/-/ > >>> merge_requests/91 > >>> This has the advantage of having the code for both versions in > >>> the same place and the Qt5 version being not stuck on some old > >>> version. Also the translations can be shared automatically since > >>> they use the same catalog. > >>> There is one case where Qt uses unversioned targets and one > >>> unversioned ecm variable but cadavidn be easily worked around. > >> > >> > >> This is good for example for phonon, and in the future and in retrospective > >> for stuff like qtcurve, but not much for kio-extras, where the codebases > >> started to diverge. > > > > I don't quite follow, as you can see it uses two different source > > directories cause the goal was to split qt5 and 6 implementations due > > to impl divergence. So in point of fact divergence is intended and > > possible. We basically have two source directories in the same branch > > and build. We believe a similar technique can be used with repos with > > little divergence just as well as for ones with huge divergence. > > The situation of kio-extras is a bit different, as the translations are not > fully shared between the two branches and I'd prefer to keep them separate. Hm. They need to have a different catalog name anyway so they don't overlap between kio-extras6 and 5 builds. We could still do that in one branch, couldn't we? e.g. - /qt6/smb/ (produces kio6_smb.pot) - /qt5/smb/ (produces kio5_smb.pot) HS
Re: kio-extras and the KF5/KF6 period
Harald Sitter ha scritto: > On Tue, Jun 20, 2023 at 2:58 PM Luigi Toscano > wrote: >> >> David Redondo ha scritto: >>> Am Mittwoch, 17. Mai 2023, 00:02:18 CEST schrieb Albert Astals Cid: kio-extras provides plugins for kio. So KF5 applications want a KF5 kio-extras and KF6 applications want a KF6 kio- extras. If we're going to support a period on which we ship both Kf5 and KF6 based applications we need to: Make sure kf5 and kf6 are coinstallable. a) release two tarballs, one for each KF b) release one tarball that compiles both for kf5 and kf6 c) just release the kf6 tarball, stop releasing the kf5 tarball but ask distributions to still install it >>> >>> Harald and I prototyped another solution to build a Qt >>> 5 and Qt 6 version out of the same repo and employed it on >>> plasma-integration: https://invent.kde.org/plasma/plasma-integration/-/ >>> merge_requests/91 >>> This has the advantage of having the code for both versions in >>> the same place and the Qt5 version being not stuck on some old >>> version. Also the translations can be shared automatically since >>> they use the same catalog. >>> There is one case where Qt uses unversioned targets and one >>> unversioned ecm variable but cadavidn be easily worked around. >> >> >> This is good for example for phonon, and in the future and in retrospective >> for stuff like qtcurve, but not much for kio-extras, where the codebases >> started to diverge. > > I don't quite follow, as you can see it uses two different source > directories cause the goal was to split qt5 and 6 implementations due > to impl divergence. So in point of fact divergence is intended and > possible. We basically have two source directories in the same branch > and build. We believe a similar technique can be used with repos with > little divergence just as well as for ones with huge divergence. The situation of kio-extras is a bit different, as the translations are not fully shared between the two branches and I'd prefer to keep them separate. Full blessing for other repositories where the difference is minimal. -- Luigi
Re: kio-extras and the KF5/KF6 period
On Tue, Jun 20, 2023 at 2:58 PM Luigi Toscano wrote: > > David Redondo ha scritto: > > Am Mittwoch, 17. Mai 2023, 00:02:18 CEST schrieb Albert Astals Cid: > >> kio-extras provides plugins for kio. > >> > >> So KF5 applications want a KF5 kio-extras and KF6 applications want a KF6 > >> kio- extras. > >> > >> If we're going to support a period on which we ship both Kf5 and KF6 based > >> applications we need to: > >> > >> Make sure kf5 and kf6 are coinstallable. > >> > >> a) release two tarballs, one for each KF > >> b) release one tarball that compiles both for kf5 and kf6 > >> c) just release the kf6 tarball, stop releasing the kf5 tarball but ask > >> distributions to still install it > >> > >> > > > > Harald and I prototyped another solution to build a Qt > > 5 and Qt 6 version out of the same repo and employed it on > > plasma-integration: https://invent.kde.org/plasma/plasma-integration/-/ > > merge_requests/91 > > This has the advantage of having the code for both versions in > > the same place and the Qt5 version being not stuck on some old > > version. Also the translations can be shared automatically since > > they use the same catalog. > > There is one case where Qt uses unversioned targets and one > > unversioned ecm variable but cadavidn be easily worked around. > > > This is good for example for phonon, and in the future and in retrospective > for stuff like qtcurve, but not much for kio-extras, where the codebases > started to diverge. I don't quite follow, as you can see it uses two different source directories cause the goal was to split qt5 and 6 implementations due to impl divergence. So in point of fact divergence is intended and possible. We basically have two source directories in the same branch and build. We believe a similar technique can be used with repos with little divergence just as well as for ones with huge divergence. HS
Re: kio-extras and the KF5/KF6 period
David Redondo ha scritto: > Am Mittwoch, 17. Mai 2023, 00:02:18 CEST schrieb Albert Astals Cid: >> kio-extras provides plugins for kio. >> >> So KF5 applications want a KF5 kio-extras and KF6 applications want a KF6 >> kio- extras. >> >> If we're going to support a period on which we ship both Kf5 and KF6 based >> applications we need to: >> >> Make sure kf5 and kf6 are coinstallable. >> >> a) release two tarballs, one for each KF >> b) release one tarball that compiles both for kf5 and kf6 >> c) just release the kf6 tarball, stop releasing the kf5 tarball but ask >> distributions to still install it >> >> > > Harald and I prototyped another solution to build a Qt > 5 and Qt 6 version out of the same repo and employed it on > plasma-integration: https://invent.kde.org/plasma/plasma-integration/-/ > merge_requests/91 > This has the advantage of having the code for both versions in > the same place and the Qt5 version being not stuck on some old > version. Also the translations can be shared automatically since > they use the same catalog. > There is one case where Qt uses unversioned targets and one > unversioned ecm variable but cadavidn be easily worked around. This is good for example for phonon, and in the future and in retrospective for stuff like qtcurve, but not much for kio-extras, where the codebases started to diverge. -- Luigi
Re: kio-extras and the KF5/KF6 period
El dijous, 25 de maig de 2023, a les 12:51:32 (CEST), Nicolas Fella va escriure: > Hi, > > Am 17.05.23 um 00:02 schrieb Albert Astals Cid: > > kio-extras provides plugins for kio. > > > > So KF5 applications want a KF5 kio-extras and KF6 applications want a KF6 > > kio- extras. > > This is also the case in more places, e.g. Breeze/Oxygen and > plasma-integration, so having a unified approach would make sense. > > > If we're going to support a period on which we ship both Kf5 and KF6 based > > applications we need to: > > > > Make sure kf5 and kf6 are coinstallable. > > > > a) release two tarballs, one for each KF > > In some cases, where there is a large enough divergence between the 5 > and 6 code we might want to have separate branches to maintain those > (e.g. master is Qt6 and we have a qt5-compat branch). > > Having separate branches would imply separate tarballs. > > How would this work with version numbers and tags? We'd have something > like v23.08.0-qt5 and v23.08.0-qt6? probably the branch name in front? I have the feeling it'd confuse the "version number extractors" a bit less. So basically kio-extras-qt5-xxx and kio-extras-qt6-xxx (or without the qt) (or with kf instead of qt). > > > b) release one tarball that compiles both for kf5 and kf6 > > This would be my preferred approach for things with little divergence > between 5 and 6, i.e. not enough divergence to justify a separate branch. > > > c) just release the kf6 tarball, stop releasing the kf5 tarball but ask > > distributions to still install it > > You mean installing the last KF5-based release? How well this works > would depend on the amount of non-bugfix work we want to put into the > Qt5 variant. This is basically a variant of a) in which no longer release a KF5-based- tarball but the distributions do some kind of renaming to make sure both the "old" KF5-based package and the "new" KF6-based package can both be installed at the same time. Cheers, Albert > > For Breeze in particular this could mean that the appearance of Qt5 and > Qt6 apps could get out of sync. > > > What's everyone's preference? > > > > Cheers, > > > >Albert > > Cheers > > Nico
Re: kio-extras and the KF5/KF6 period
Hi, Am 17.05.23 um 00:02 schrieb Albert Astals Cid: kio-extras provides plugins for kio. So KF5 applications want a KF5 kio-extras and KF6 applications want a KF6 kio- extras. This is also the case in more places, e.g. Breeze/Oxygen and plasma-integration, so having a unified approach would make sense. If we're going to support a period on which we ship both Kf5 and KF6 based applications we need to: Make sure kf5 and kf6 are coinstallable. a) release two tarballs, one for each KF In some cases, where there is a large enough divergence between the 5 and 6 code we might want to have separate branches to maintain those (e.g. master is Qt6 and we have a qt5-compat branch). Having separate branches would imply separate tarballs. How would this work with version numbers and tags? We'd have something like v23.08.0-qt5 and v23.08.0-qt6? b) release one tarball that compiles both for kf5 and kf6 This would be my preferred approach for things with little divergence between 5 and 6, i.e. not enough divergence to justify a separate branch. c) just release the kf6 tarball, stop releasing the kf5 tarball but ask distributions to still install it You mean installing the last KF5-based release? How well this works would depend on the amount of non-bugfix work we want to put into the Qt5 variant. For Breeze in particular this could mean that the appearance of Qt5 and Qt6 apps could get out of sync. What's everyone's preference? Cheers, Albert Cheers Nico
Re: kio-extras and the KF5/KF6 period
Hi, On Wednesday, May 17, 2023 00:02 CEST, Albert Astals Cid wrote: > If we're going to support a period on which we ship both Kf5 and KF6 based > applications we need to: > > Make sure kf5 and kf6 are coinstallable. I'm currently packaging a first KF6 snapshot in OpenMandriva. Looks pretty good already, but there's still a few problems with coinstallability, esp. when building man pages is enabled (some of them still have *5 names, conflicting with the identical parts in kf5, even where corresponding binaries have been renamed). Of course some bits like kded still use conflicting *5 names even for the core parts. > a) release two tarballs, one for each KF > b) release one tarball that compiles both for kf5 and kf6 > c) just release the kf6 tarball, stop releasing the kf5 tarball but ask > distributions to still install it > > What's everyone's preference? Depends: If the code is virtually the same with a few ifdefs, b) is good to make sure the kf5 version still gets fixes when all development has moved on. If the divergence becomes too big, either a) or c) works for us - probably no need for frequent releases of the kf5 version (so that would be c) + possibly a kf5 release if a major bug is found/fixed, but not necessarily with every kf6 release). ttyl bero
kio-extras and the KF5/KF6 period
kio-extras provides plugins for kio. So KF5 applications want a KF5 kio-extras and KF6 applications want a KF6 kio- extras. If we're going to support a period on which we ship both Kf5 and KF6 based applications we need to: Make sure kf5 and kf6 are coinstallable. a) release two tarballs, one for each KF b) release one tarball that compiles both for kf5 and kf6 c) just release the kf6 tarball, stop releasing the kf5 tarball but ask distributions to still install it What's everyone's preference? Cheers, Albert
