Stable branches, including frameworks for Kubuntu LTS

[Allen Winter]

not sure if this is clear:  you'll fix the bugs in the master branches and
backport those fixes to the current release branch and to the LTS branch?
and you won't add new features as this is only about fixing bugs?


On Thu, May 14, 2026 at 10:26 AM Martin Flöser <mgraesslin at kde.org> wrote:

> Am Dienstag, 12. Mai 2026, 18:15:44 Mitteleuropäische Sommerzeit schrieb
> Marco
> Martin:
> > Hi all,
> > I'm speaking with my Techpaladin hat here. We have a client (Kubuntu
> Focus,
> > which they are KDE patrons as well) which is interested in long
> commercial
> > support for Plasma 6.6, alongside accompanying Gear applications and
> > frameworks.
> > This is for Kubuntu 26.04 LTS, which means:
> > * Plasma 6.6
> > * Frameworks 6.24
> > * Gear 25.12 (unfortunately not 26.4)
>
> Let me congratulate and thank both Kubuntu Focus and Techpaladin for doing
> this important work and wanting to do it upstream!
>
> I find this effort so awesome that I thought I have to answer on it :-)
> >
> > We would continue to backport and test the relevant bugfixes for the time
> > being,
> > point releases would continue to be made out of such backports.
> >
> > They will also sponsor to the eV the necessary CI nodes to continue CI
> for
> > those branches, as long they are supported.
> >
> > Now the delicate part is frameworks, which as of today it doesn't have a
> > stable branch, but since Kubuntu can't upgrade frameworks in its LTS,
> such
> > a stable maintenance branch would need to be created, which would be a
> > first.
> >
> > We (as in Techpaladin) pledge to take up the maintenance of such branch
> as
> > long as it's supported, managing backports, testing and releases, as well
> > as keeping the new CI nodes green
>
> I think there is no problem using the normal branch names without any
> Kubuntu
> or Enterprise branch naming. The only important thing is that the
> communication is clear:
>
>  * no expectation that there will be another LTS branch in future
>  * corporate backing, no community effort
>  * no promises from community
>  * no expectations that bugs get backported
>  * community members should not be pushed into backporting
>
> The last point might also require that we prepare some text templates for
> social media and bug reports when users demand that a bug fix gets
> backported.
>
> Cheers
> Martin
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20260514/d9dad487/attachment.htm>