Proposal unify back our release schedules

[Michael Reeves]

For the same reason they are sometimes seen as convenient this type of container format can be a pain when a security patch or bug fix needs to be propagated to every app that uses a library on an individual basis.
Also some app image formats like flatpak are very restrictive by default on what they allow an app to do. Something to think about as we will get bugs related to that if app images become the primary distribution mechanism.

Apr 24, 2024 1:56:30 PM Martin Flöser <mgraesslin at kde.org>:

> Am Freitag, 19. April 2024, 11:04:33 CEST schrieb Carl Schwan:
>> Currently this is just a proposal, not a vote proposal or anything like
>> that. I'll be happy to receive positive or negative feedback on this idea.
> 
> Reading through the proposal and the discussion, I think we need to think a
> little bit outside of the box. I have the feeling that most devs still see
> Linux distributions as the primary way to distribute our software. I do not
> think that this is universal true anymore and if we move away from it, this
> would open up way new possibilities.
> 
> Let's assume for apps we see Flathub/Snaps/Windows Store/whatever store as our
> primary distribution channel, this would give us quite some advantages:
> 
> * less duplicated work for distributions
> * no problems with "this framework release is not packaged yet"
> * no overwhelmed work for distributions due to too many packages need to be
> updated
> * no need to push an update if nothing changed
> * no random "this pulls in KDE" due to incorrect packaging
> * always up to date software for our users
> * no bad experience due to missing (optional) dependencies
> * easy release for the maintainers without needing a release team (what about
> a Gitlab create release pipeline the maintainer can press)
> 
> So this would totally open up a new way to release and distribute "Gear". And
> with Gear being easily available for everyone this would also give the
> possibility to move things into Plasma which belong into Plasma, but haven't
> been for "this is an app and also usable on other desktop". What comes in my
> mind is everything that are essential apps for a decent desktop experience:
> 
> * dolphin
> * spectacle
> * an image viewer (gwenview/koko, etc.)
> * okular
> * ...
> 
> Those could still be apps, but be released together with Plasma, thus also
> tightly integrate with Plasma while at the same time be distributed through
> other channels.
> 
> Such a model should also help with the development experience. I read a few
> comments about it being a problem on depending on frameworks master - I agree
> that is a problem. But not so much if there is always an up to date
> development container available to pull and hack on. If apps are
> containerized, their build environment can also be containerized.
> 
> So my suggestion: think about more than just the release cycle and the
> alignment of the releases if you are going to touch this (hot) topic.
> 
> Cheers
> Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 854 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20240424/6e8ee80c/attachment.sig>