Re: Advance FW 6.30? (Was: Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9)

[Martin Riethmayer]

Am 04.03.26 um 13:00 schrieb Nicolas Fella:


Hi,

we can do that. Should we do it on the same day as the Plasma beta?




Bhushan said on Plasma devel chat that releases on the same day aren't 
ideal, I also don't know if there's a possible CI shortage for double 
releases?
I'm only updating the wiki and proposing the schedule, so I don't have 
any preference either way, as other people are doing the heavy lifting 
here...
From what I'm reading, I would guess that having FW one day before 
Plasma would likely be better?


Best regards

Martin

Re: Advance FW 6.30? (Was: Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9)

[Nicolas Fella]

On 3/3/26 12:31 PM, Martin Riethmayer wrote:

Hello Release-Team,

following up Davids mail to plasma-devel (see below): There's an idea 
to release Plasma 6.8 on KDEs 30th birthday (i.e. release 6.8.0 on 
October 14th). [1]


This would shift dates slightly for all versions before (soft freeze, 
betas and tar-creation) and would result in Plasma 6.8 missing the 
release of FW 6.30 by one day (if normal timings are kept).


Would it be possible to advance the release of FW 6.30 by 1-2 days? 
I.e. 6.30 would be released on September 9th or 10th instead of 
September 11th.


Other alternatives I can see (there may be more, of course):
- use FW 6.29 for Plasma 6.8
- delay Plasma 6.7.90 by 2 days (it would shorten the beta period for 
beta 1, presumably, by those 2 days)


Best regards

Martin

[1] https://invent.kde.org/teams/promo/30th-anniversary/-/work_items/7

Am 02.03.26 um 10:08 schrieb David Redondo:

Am Dienstag, 13. Januar 2026, 16:13 schrieb Martin Riethmayer:

Hi everyone,
[]




+ [Plasma 6.8.] +
6.7.80    2026-09-03
6.7.90    2026-09-17 [Note5]
6.7.91    2026-10-01
TAR    2026-10-15
6.8.0    2026-10-20
6.8.1    2026-10-27
6.8.2    2026-11-03
6.8.3    2026-11-17
6.8.4    2026-12-08
6.8.5    2027-01-12
6.8.6    2027-03-16 [Note6]

as all of you know this year is the 30th anniversary of KDE. Like we 
did for
5.23 and the 25th anniversary let's make 6.8 the 30th anniversary 
edition.
We released 5.23 on the day of the anniversary, I propose we do the 
same for

6.8. See also: https://invent.kde.org/teams/promo/30th-anniversary/-/
work_items/7
I propose:
Shift the release dates by a week so 6.8.0 releases on the 14th of 
October.

The patch and beta releases could keep their day of the week. In detail:

  + [Plasma 6.8.] +
  6.7.80    2026-08-27
  6.7.90    2026-09-10 ¹
  6.7.91    2026-09-24
  TAR    2026-10-08
  6.8.0    2026-10-14
  6.8.1    2026-10-20
  6.8.2    2026-10-27
  6.8.3    2026-11-10
  6.8.4    2026-12-01
  6.8.5    2027-01-05
  6.8.6    2027-03-02

¹ this means we would miss the proposed frameworks released on the 
11th, maybe

delay or ask Nicolas to release frameworks a bit earlier?

Cheers,
David 


Hi,

we can do that. Should we do it on the same day as the Plasma beta?

Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9

[Bhushan Shah]

On Tuesday, 3 March 2026 15:55:41 IST David Redondo wrote:
> We did Plasma 6.2.90 and Frameworks 6.10 on the same day in the past even.

Please let's not do releases on same day. (again :P)


signature.asc
Description: This is a digitally signed message part.

Advance FW 6.30? (Was: Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9)

[Martin Riethmayer]

Hello Release-Team,

following up Davids mail to plasma-devel (see below): There's an idea to 
release Plasma 6.8 on KDEs 30th birthday (i.e. release 6.8.0 on October 
14th). [1]


This would shift dates slightly for all versions before (soft freeze, 
betas and tar-creation) and would result in Plasma 6.8 missing the 
release of FW 6.30 by one day (if normal timings are kept).


Would it be possible to advance the release of FW 6.30 by 1-2 days? I.e. 
6.30 would be released on September 9th or 10th instead of September 11th.


Other alternatives I can see (there may be more, of course):
- use FW 6.29 for Plasma 6.8
- delay Plasma 6.7.90 by 2 days (it would shorten the beta period for 
beta 1, presumably, by those 2 days)


Best regards

Martin

[1] https://invent.kde.org/teams/promo/30th-anniversary/-/work_items/7

Am 02.03.26 um 10:08 schrieb David Redondo:

Am Dienstag, 13. Januar 2026, 16:13 schrieb Martin Riethmayer:

Hi everyone,
[]




+ [Plasma 6.8.] +
6.7.80  2026-09-03
6.7.90  2026-09-17 [Note5]
6.7.91  2026-10-01
TAR 2026-10-15
6.8.0   2026-10-20
6.8.1   2026-10-27
6.8.2   2026-11-03
6.8.3   2026-11-17
6.8.4   2026-12-08
6.8.5   2027-01-12
6.8.6   2027-03-16 [Note6]


as all of you know this year is the 30th anniversary of KDE. Like we did for
5.23 and the 25th anniversary let's make 6.8 the 30th anniversary edition.
We released 5.23 on the day of the anniversary, I propose we do the same for
6.8. See also: https://invent.kde.org/teams/promo/30th-anniversary/-/
work_items/7
I propose:
Shift the release dates by a week so 6.8.0 releases on the 14th of October.
The patch and beta releases could keep their day of the week. In detail:

  + [Plasma 6.8.] +
  6.7.802026-08-27
  6.7.902026-09-10 ¹
  6.7.912026-09-24
  TAR   2026-10-08
  6.8.0 2026-10-14
  6.8.1 2026-10-20
  6.8.2 2026-10-27
  6.8.3 2026-11-10
  6.8.4 2026-12-01
  6.8.5 2027-01-05
  6.8.6 2027-03-02

¹ this means we would miss the proposed frameworks released on the 11th, maybe
delay or ask Nicolas to release frameworks a bit earlier?

Cheers,
David

Re: Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9

[David Redondo]

Am Montag, 2. März 2026, 20:13 schrieb Martin Riethmayer:
> 
> >   6.7.902026-09-10 ¹
> > [...]
> > ¹ this means we would miss the proposed frameworks released on the 11th, 
> > maybe
> > delay or ask Nicolas to release frameworks a bit earlier?
> 
> What would "a bit earlier" be, ideally? A whole week or is 2-3 days 
> enough time?
> 

We did Plasma 6.2.90 and Frameworks 6.10 on the same day in the past even.

David

Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9

[Martin Riethmayer]

  6.7.902026-09-10 ¹
[...]
¹ this means we would miss the proposed frameworks released on the 11th, maybe
delay or ask Nicolas to release frameworks a bit earlier?


What would "a bit earlier" be, ideally? A whole week or is 2-3 days 
enough time?


Best regards

Martin



Cheers,
David

Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9

[David Redondo]

Am Dienstag, 13. Januar 2026, 16:13 schrieb Martin Riethmayer:
> Hi everyone,
> []

> 
> + [Plasma 6.8.] +
> 6.7.802026-09-03
> 6.7.902026-09-17 [Note5]
> 6.7.912026-10-01
> TAR   2026-10-15
> 6.8.0 2026-10-20
> 6.8.1 2026-10-27
> 6.8.2 2026-11-03
> 6.8.3 2026-11-17
> 6.8.4 2026-12-08
> 6.8.5 2027-01-12
> 6.8.6 2027-03-16 [Note6]
>
as all of you know this year is the 30th anniversary of KDE. Like we did for 
5.23 and the 25th anniversary let's make 6.8 the 30th anniversary edition.
We released 5.23 on the day of the anniversary, I propose we do the same for
6.8. See also: https://invent.kde.org/teams/promo/30th-anniversary/-/
work_items/7
I propose:
Shift the release dates by a week so 6.8.0 releases on the 14th of October. 
The patch and beta releases could keep their day of the week. In detail:

 + [Plasma 6.8.] +
 6.7.80 2026-08-27
 6.7.90 2026-09-10 ¹
 6.7.91 2026-10-24
 TAR2026-10-08
 6.8.0  2026-10-14
 6.8.1  2026-10-20
 6.8.2  2026-10-27
 6.8.3  2026-11-10
 6.8.4  2026-12-01
 6.8.5  2027-01-05
 6.8.6  2027-03-02

¹ this means we would miss the proposed frameworks released on the 11th, maybe 
delay or ask Nicolas to release frameworks a bit earlier?

Cheers,
David

Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9

[David Edmundson]

1.) Releasing 6.7.7 two weeks earlier (wrt Fibonacci): 2027-01-19

That sounds fine.

Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9

[Martin Riethmayer]

Am 18. Januar 2026 20:27:29 MEZ schrieb David Edmundson 
:


6.8.80 2027-01-07 [Note7]


This is when 6.9 branches, which means we can't do 6.7.7 in this 
schedule.



Am 19.01.26 um 15:28 schrieb Martin Riethmayer:


[...] I'm guessing that 6.7.7 should be released before the
branching happens?

Any preference on either moving 6.7.7 ahead in time or postponing 
6.9 (by about 2 weeks)? Delaying 6.9 might cause a scheduling issue 
with Kubuntu 2704, as the initial 6.9.0 would be 2027-03-09 .


My proposal so far had branching of Plasma 6.9  happening on 2027-01-21
(6.8.90).

The three options (IMO) to release 6.7.7 before branching are:
1.) Releasing 6.7.7 two weeks earlier (wrt Fibonacci): 2027-01-19
2.) Branching of 6.9 is delayed by two weeks: 2027-02-04 (which would
result in a release date of 2027-03-09)
3.) Mix of 1+2: Release 6.7.7 one week earlier (2027-01-26) and delay
branching of 6.9 by one week (2027-01-28).

As my proposed 6.9 schedule is already a bit later than the usual
"northern-hemisphere-winter" releases, delaying further might
cause issues with some distribution schedules.

Any thoughts on this?

Best regards

Martin





Best regards

Martin

Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9

[Martin Riethmayer]

Isn't branching happening on 6.8.90 (i.e. 2027-01-21 )? 

Anyway, I'm guessing that 6.7.7 should be released before the branching 
happens? 

Any preference on either moving 6.7.7 ahead in time or postponing 6.9 (by about 
2 weeks)? Delaying 6.9 might cause a scheduling issue with Kubuntu 2704, as the 
initial 6.9.0 would be 2027-03-09 .

Best regards 

Martin 

Am 18. Januar 2026 20:27:29 MEZ schrieb David Edmundson 
:
>> 6.8.80  2027-01-07 [Note7]
>
>This is when 6.9 branches, which means we can't do 6.7.7 in this schedule.

Re: Dropping X11 in Plasma 6.7 (was Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9)

[Alberto Salvia Novella]

I will reporting bugs, and investigating their root causes.

Cheers! 👍

On Sun, Jan 18, 2026 at 10:07 PM David Edmundson 
wrote:

>
>
> On Sun, 18 Jan 2026, 21:00 Nate Graham,  wrote:
>
>> [re-titling subject line to make it a new thread]
>>
>> The larger context here is that after decades of service, the world is
>> moving on from X11.
>>
>> It's a trend bigger than KDE, but we're a part of it too: almost no
>> Plasma developers are still regularly using or developing the X11
>> session. Upstream X11 development also largely ended years ago, except
>> for development of the XWayland compatibility layer. Most distros are
>> moving on, too, either having already switched to Plasma Wayland by
>> default, or were already making active plans to do so.
>>
>> However, I can appreciate the stress of losing something that from your
>> perspective is working fine — especially if the successor isn't working
>> as well for your use cases.
>>
>> So now is the time to articulate what's still painful about Wayland for
>> you *that's not already mentioned on
>> https://community.kde.org/Plasma/Wayland_Known_Significant_Issues*,
>> because we have a year or so to address those concerns. And addressing
>> as many of them as possible is the goal!
>>
>
> In addition, the Reddit thread linked has a lot of things that are simply
> not true in Plasma. We have gone to a lot of efforts for compatibility in
> ways that's aren't true for all desktops.
>
> I don't want generic Wayland rants, but things that are actually vetted
> and relevant to us.
>
> David
>

Re: Dropping X11 in Plasma 6.7 (was Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9)

[David Edmundson]

On Sun, 18 Jan 2026, 21:00 Nate Graham,  wrote:

> [re-titling subject line to make it a new thread]
>
> The larger context here is that after decades of service, the world is
> moving on from X11.
>
> It's a trend bigger than KDE, but we're a part of it too: almost no
> Plasma developers are still regularly using or developing the X11
> session. Upstream X11 development also largely ended years ago, except
> for development of the XWayland compatibility layer. Most distros are
> moving on, too, either having already switched to Plasma Wayland by
> default, or were already making active plans to do so.
>
> However, I can appreciate the stress of losing something that from your
> perspective is working fine — especially if the successor isn't working
> as well for your use cases.
>
> So now is the time to articulate what's still painful about Wayland for
> you *that's not already mentioned on
> https://community.kde.org/Plasma/Wayland_Known_Significant_Issues*,
> because we have a year or so to address those concerns. And addressing
> as many of them as possible is the goal!
>

In addition, the Reddit thread linked has a lot of things that are simply
not true in Plasma. We have gone to a lot of efforts for compatibility in
ways that's aren't true for all desktops.

I don't want generic Wayland rants, but things that are actually vetted and
relevant to us.

David

Dropping X11 in Plasma 6.7 (was Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9)

[Nate Graham]

[re-titling subject line to make it a new thread]

The larger context here is that after decades of service, the world is 
moving on from X11.


It's a trend bigger than KDE, but we're a part of it too: almost no 
Plasma developers are still regularly using or developing the X11 
session. Upstream X11 development also largely ended years ago, except 
for development of the XWayland compatibility layer. Most distros are 
moving on, too, either having already switched to Plasma Wayland by 
default, or were already making active plans to do so.


However, I can appreciate the stress of losing something that from your 
perspective is working fine — especially if the successor isn't working 
as well for your use cases.


So now is the time to articulate what's still painful about Wayland for 
you *that's not already mentioned on 
https://community.kde.org/Plasma/Wayland_Known_Significant_Issues*, 
because we have a year or so to address those concerns. And addressing 
as many of them as possible is the goal!


So it's a "help us help you" situation. Please do let us know what's not 
working well for you, and remember to do it in a way that maximizes the 
chances of your concern being taken seriously: be polite and 
constructive, remember your manners, offer to help develop or test 
fixes, etc. There are even crowdfunding[1] and commercial[2] 
opportunities if things aren't moving as fast as you'd prefer.


Thanks, folks!


Nate



[1] https://discuss.kde.org/c/development/sponsored-work/31
[2] https://ev.kde.org/consultants

Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9

[David Edmundson]

On Sat, Jan 17, 2026 at 1:00 PM Piotr H. Dabrowski  wrote:
>
> Hi,
>
> > with Plasma 6.7 being the last version with X11 support
> > 6.7.7 2027-02-02
>
> I think dropping support for an ACTUALLY WORKING, VERY STABLE, and 
> BATTLE-TESTED environment like Xorg/XLibre in favor of a solution where even 
> the underlying protocol design is still effectively in an alpha state, valid 
> use cases are broken, and basic core features are still missing and still 
> actively debated among developers, is pretty insane. Literally.
>

This is a thread about release timing which is very important. If
anyone posts about things that aren't releasing timings in this thread
I *will* ban them.
You can make another thread if you want.

David

Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9

[David Edmundson]

> 6.8.80  2027-01-07 [Note7]

This is when 6.9 branches, which means we can't do 6.7.7 in this schedule.

Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9

[Alberto Salvia Novella]

https://youtu.be/Fm99TROo3LE

On Sat, Jan 17, 2026 at 2:35 PM Alberto Salvia Novella <
es204904...@gmail.com> wrote:

> I believe that a bunch things criticized to Xorg are actually its greatest
> strengths:
> - A single code stack for all desktop environments. Standardization by
> design.
> - Separation of the mechanisms from the policies. Let the client decide.
> - No isolation within components. Simple communication among them.
>
>
> Following the same trend as Wayland, about the fork of SDDM, for deeper
> integration at the expense of portability, I have to say that Zenned has
> always avoided such integration.
>
> The very polished Zenned login screen
>  is coded in pure QML,
> and it only has the password prompt and two power buttons. Everything else,
> like power indicators or notifications, is deemed useless in a screen which
> is intended to be seen just a few seconds.
>
>
> Coming back to Wayland, these are the reasons why currently Zenned hasn't
> adopted it yet as the default session:
>
> The ugliest: Non-maximizable windows are broken with placement policy set
> as maximized . Windows are
> not decorated, and choppy when moved.
>
> Also X11 + Autocomposer  has
> noticeable lower latency than Wayland. It is specially noticeable with the
> mouse cursor. It doesn't matter how much lightweight the window rendering
> is, if the mouse movement is laggy or inconsistent. When gaming you
> perceive full screen camera movements as laggy, even if the rendering has
> decent latency.
>
> On Nvidia Optimus the mouse latency is only decent while installing Optimus
> Manager , which keeps the iGPU
> at maximum clocks. Otherwise this bug
>  happens.
>
> I suspect these latency differences are not noticeable to most KDE
> developers because they either don't have an NVIDIA GPU, a high polling
> rate mouse, or a high frame-rate screen. But the three are currently
> important for a quality gaming experience, and most gamers will gave them.
>
> Summarizing, from the current user perspective: why using Wayland, when
> using X11 has lower more consistent latency on games?
>
> On Sat, Jan 17, 2026 at 2:00 PM Piotr H. Dabrowski  wrote:
>
>> Hi,
>>
>> > with Plasma 6.7 being the last version with X11 support
>> > 6.7.7 2027-02-02
>>
>> I think dropping support for an ACTUALLY WORKING, VERY STABLE, and
>> BATTLE-TESTED environment like Xorg/XLibre in favor of a solution where
>> even the underlying protocol design is still effectively in an alpha state,
>> valid use cases are broken, and basic core features are still missing and
>> still actively debated among developers, is pretty insane. Literally.
>>
>> I would like to hear a MERITORIOUS reply to these concerns:
>>
>>
>> https://www.reddit.com/r/linux/comments/1pxectw/wayland_is_flawed_at_its_core_and_the_community/
>>
>>
>> https://www.semicomplete.com/blog/xdotool-and-exploring-wayland-fragmentation/
>>
>> https://vas.neocities.org/wayland_shitware
>>
>> https://news.ycombinator.com/item?id=44301194
>>
>> Namely:
>> - no mouse-grabbing protocol; pointer-warp protocol is still broken
>> (required by virtually every game)
>> - screen sharing is still broken
>> - color management is still broken
>> - automation tools are broken (xdotool)
>> - global hotkeys broken
>> - accessibility features can’t be properly implemented
>> - no sane capabilities system
>> - no standard way to communicate with the window manager (like EWMH)
>> - fragmentation hell: no DE is required to implement any protocol, no API
>> can be considered reliable
>> - every new feature requires a new protocol and multiple, DE-specific
>> implementations, which will take years to become even remotely useful
>> ...and much more.
>> READ the actual articles; it's 10 minutes of work spent on actually
>> listening to the community.
>>
>> Wayland is unusable for the majority of Linux users, based on the use
>> cases described and the numerous comments above.
>> Are you willing to take our voices into consideration, or will you
>> continue to ignore us?
>>
>> Power-users, in particular, will be hurt by you ignoring our needs. KDE
>> has always been the desktop environment that supported us.
>> Do you remember "Simple by Default, Powerful when Needed"? With Wayland,
>> it feels more like "Broken by Default, Powerful Never".
>>
>> I am fully in favor of replacing old X11 with something modern and
>> better, but Wayland is either not that solution, or at the very least, it
>> is not ready yet.
>>
>> That said, there should obviously be NO END DATE SCHEDULED FOR X11
>> SUPPORT.
>> Maybe we can have this discussion again in 5 years or so, when Wayland is
>> (hopefully) ready and actually usable.
>>
>> Once again: stop ignoring valid concerns and provide meritorious
>> responses instead of avo

Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9

[Alberto Salvia Novella]

I believe that a bunch things criticized to Xorg are actually its greatest
strengths:
- A single code stack for all desktop environments. Standardization by
design.
- Separation of the mechanisms from the policies. Let the client decide.
- No isolation within components. Simple communication among them.


Following the same trend as Wayland, about the fork of SDDM, for deeper
integration at the expense of portability, I have to say that Zenned has
always avoided such integration.

The very polished Zenned login screen
 is coded in pure QML, and
it only has the password prompt and two power buttons. Everything else,
like power indicators or notifications, is deemed useless in a screen which
is intended to be seen just a few seconds.


Coming back to Wayland, these are the reasons why currently Zenned hasn't
adopted it yet as the default session:

The ugliest: Non-maximizable windows are broken with placement policy set
as maximized . Windows are not
decorated, and choppy when moved.

Also X11 + Autocomposer  has
noticeable lower latency than Wayland. It is specially noticeable with the
mouse cursor. It doesn't matter how much lightweight the window rendering
is, if the mouse movement is laggy or inconsistent. When gaming you
perceive full screen camera movements as laggy, even if the rendering has
decent latency.

On Nvidia Optimus the mouse latency is only decent while installing Optimus
Manager , which keeps the iGPU
at maximum clocks. Otherwise this bug
 happens.

I suspect these latency differences are not noticeable to most KDE
developers because they either don't have an NVIDIA GPU, a high polling
rate mouse, or a high frame-rate screen. But the three are currently
important for a quality gaming experience, and most gamers will gave them.

Summarizing, from the current user perspective: why using Wayland, when
using X11 has lower more consistent latency on games?

On Sat, Jan 17, 2026 at 2:00 PM Piotr H. Dabrowski  wrote:

> Hi,
>
> > with Plasma 6.7 being the last version with X11 support
> > 6.7.7 2027-02-02
>
> I think dropping support for an ACTUALLY WORKING, VERY STABLE, and
> BATTLE-TESTED environment like Xorg/XLibre in favor of a solution where
> even the underlying protocol design is still effectively in an alpha state,
> valid use cases are broken, and basic core features are still missing and
> still actively debated among developers, is pretty insane. Literally.
>
> I would like to hear a MERITORIOUS reply to these concerns:
>
>
> https://www.reddit.com/r/linux/comments/1pxectw/wayland_is_flawed_at_its_core_and_the_community/
>
>
> https://www.semicomplete.com/blog/xdotool-and-exploring-wayland-fragmentation/
>
> https://vas.neocities.org/wayland_shitware
>
> https://news.ycombinator.com/item?id=44301194
>
> Namely:
> - no mouse-grabbing protocol; pointer-warp protocol is still broken
> (required by virtually every game)
> - screen sharing is still broken
> - color management is still broken
> - automation tools are broken (xdotool)
> - global hotkeys broken
> - accessibility features can’t be properly implemented
> - no sane capabilities system
> - no standard way to communicate with the window manager (like EWMH)
> - fragmentation hell: no DE is required to implement any protocol, no API
> can be considered reliable
> - every new feature requires a new protocol and multiple, DE-specific
> implementations, which will take years to become even remotely useful
> ...and much more.
> READ the actual articles; it's 10 minutes of work spent on actually
> listening to the community.
>
> Wayland is unusable for the majority of Linux users, based on the use
> cases described and the numerous comments above.
> Are you willing to take our voices into consideration, or will you
> continue to ignore us?
>
> Power-users, in particular, will be hurt by you ignoring our needs. KDE
> has always been the desktop environment that supported us.
> Do you remember "Simple by Default, Powerful when Needed"? With Wayland,
> it feels more like "Broken by Default, Powerful Never".
>
> I am fully in favor of replacing old X11 with something modern and better,
> but Wayland is either not that solution, or at the very least, it is not
> ready yet.
>
> That said, there should obviously be NO END DATE SCHEDULED FOR X11 SUPPORT.
> Maybe we can have this discussion again in 5 years or so, when Wayland is
> (hopefully) ready and actually usable.
>
> Once again: stop ignoring valid concerns and provide meritorious responses
> instead of avoiding the topic. Otherwise, this will end badly for the
> entire Linux community.
>
> Best Regards,
> Piotr H. Dabrowski
>
>
>
> Hi everyone,
>>
>> with Plasma 6.7 being the last version with X11 support [1] and the idea
>> that "6.7 would get support until 6.9 bran

Re: Draft: Release schedules for Plasma 6.7, 6.8 and 6.9

[Piotr H. Dabrowski]

Hi,

> with Plasma 6.7 being the last version with X11 support
> 6.7.7 2027-02-02

I think dropping support for an ACTUALLY WORKING, VERY STABLE, and
BATTLE-TESTED environment like Xorg/XLibre in favor of a solution where
even the underlying protocol design is still effectively in an alpha state,
valid use cases are broken, and basic core features are still missing and
still actively debated among developers, is pretty insane. Literally.

I would like to hear a MERITORIOUS reply to these concerns:

https://www.reddit.com/r/linux/comments/1pxectw/wayland_is_flawed_at_its_core_and_the_community/

https://www.semicomplete.com/blog/xdotool-and-exploring-wayland-fragmentation/

https://vas.neocities.org/wayland_shitware

https://news.ycombinator.com/item?id=44301194

Namely:
- no mouse-grabbing protocol; pointer-warp protocol is still broken
(required by virtually every game)
- screen sharing is still broken
- color management is still broken
- automation tools are broken (xdotool)
- global hotkeys broken
- accessibility features can’t be properly implemented
- no sane capabilities system
- no standard way to communicate with the window manager (like EWMH)
- fragmentation hell: no DE is required to implement any protocol, no API
can be considered reliable
- every new feature requires a new protocol and multiple, DE-specific
implementations, which will take years to become even remotely useful
...and much more.
READ the actual articles; it's 10 minutes of work spent on actually
listening to the community.

Wayland is unusable for the majority of Linux users, based on the use cases
described and the numerous comments above.
Are you willing to take our voices into consideration, or will you continue
to ignore us?

Power-users, in particular, will be hurt by you ignoring our needs. KDE has
always been the desktop environment that supported us.
Do you remember "Simple by Default, Powerful when Needed"? With Wayland, it
feels more like "Broken by Default, Powerful Never".

I am fully in favor of replacing old X11 with something modern and better,
but Wayland is either not that solution, or at the very least, it is not
ready yet.

That said, there should obviously be NO END DATE SCHEDULED FOR X11 SUPPORT.
Maybe we can have this discussion again in 5 years or so, when Wayland is
(hopefully) ready and actually usable.

Once again: stop ignoring valid concerns and provide meritorious responses
instead of avoiding the topic. Otherwise, this will end badly for the
entire Linux community.

Best Regards,
Piotr H. Dabrowski



Hi everyone,
>
> with Plasma 6.7 being the last version with X11 support [1] and the idea
> that "6.7 would get support until 6.9 branches" (David Edmundson, [2] ),
> I re-visited my proposed schedule and also created a draft schedule for
> 6.8 and 6.9.
>
> This will be a bit of a longer e-mail, sorry, I'll try to keep it as
> short as possible.
>
> + [Plasma 6.7.] +
> 6.6.80  2026-04-30
> 6.6.90  2026-05-14 [Note1]
> 6.6.91  2026-05-28
> TAR 2026-06-11
> 6.7.0   2026-06-16
> 6.7.1   2026-06-23
> 6.7.2   2026-06-30
> 6.7.3   2026-07-14
> 6.7.4   2026-08-04
> 6.7.5   2026-09-08
> 6.7.6   2026-11-10 [Note2]
> 6.7.7   2027-02-02 [Note3, Note4]
>
> Versions:
> Qt: Stay on 6.10 (as agreed upon in the last e-mail thread and on Matrix
> discussion)
> KDE FW: 6.26
>
> Notes:
> [General / CI]
> I'm not sure how the CI situation will work out for one extra release of
> Plasma 6.7. There were some concerns raised by Ben Cooksley [4], though
> that was with my then drafted 6.7.8 bugfix release, which has been
> dropped. The current proposal would end the 6.7 series with 6.7.7 .
>
> [Note1] This is the Thursday following the corresponding Frameworks
> release ("expected May 8th"). It's also 2 days after 6.6.5, but that
> should be OK?
>
> [Note2] Delayed by one week with regard to the Fibonacci sequence to
> avoid conflict with 6.8.2
>
> [Note3] As can be seen further down this e-mail, this is about 2 weeks
> after tagging of Plasma 6.9 (scheduled for 2027-01-21)
>
> [Note4] Even though this is one extra release compared to other Plasma
> versions, consesus so far seems to be to not call this an "LTS" release
> publicly.
> + [/Plasma 6.7.] +
>
>
>
> + [Plasma 6.8.] +
> 6.7.80  2026-09-03
> 6.7.90  2026-09-17 [Note5]
> 6.7.91  2026-10-01
> TAR 2026-10-15
> 6.8.0   2026-10-20
> 6.8.1   2026-10-27
> 6.8.2   2026-11-03
> 6.8.3   2026-11-17
> 6.8.4   2026-12-08
> 6.8.5   2027-01-12
> 6.8.6   2027-03-16 [Note6]
>
> Versions:
> Qt: TBD (Staying with Qt 6.10 or Qt 6.11 would be possible, released
> "March 2026"[3])
> KDE FW: 6.30
>
> Notes:
> [Note5] Thursday after corresponding Frameworks release ("expected Sept.
> 11th")
> [Note6] Delayed by one week with regard to the Fibonacci sequence to
> avoid conflict wi