Thanks for taking the time to assemble this email, Carl. These are
arguments I've brought up individually myself for years, and I think
they have merit.
Taken together, for me they paint a picture of a project that was
attempted, faithfully executed on, but didn't end up delivering the
benefits we hoped for while introducing some new drawbacks that have no
easy path to being resolved. I'm in favor.
I expect a vast amount of discussion to result from this proposal, and I
think that's great. It'll be good to talk about it. But I suspect in the
end we'll likely not achieve 100% consensus, and in that event I'd like
for us to put it to a formal KDE e.V. vote so that the topic doesn't
become stale and die after everyone's exhausted from a long discussion.
Nate
On 4/19/24 11:04, Carl Schwan wrote:
Hello Community,
I know this might be a controversial idea, but I would like to propose reunify
our release schedules. I feel like splitting our releases schedules between
Frameworks, Plasma and Gear is not working as well as we intended it to be when
we split the releases schedules for Plasma 5. This is for multiple reasons:
* We end up with 3 different products which are released at different times but
are connected together. Apps and Plasma both need Framework, Plasma needs
some
packages from gear like kio-extra, Gear needs some package from Plasma like
Breeze. Coordinating all these inter-groups dependencies is complex and was
one
the reason we had to do a megarelease for Plasma 6. Also for the end user,
one
product is a lot easier to understand.
* This results in very frequent releases which creates a lot of work for distros
and talking with some distro maintainers they seems to agree that having a
big
releases every 4 months is better than having constantly a new minor or major
release from either Framework, Gear or Plasma.
* We currently don't have a stable branch for Framework and it takes often up to
one month for fixes to be deployed. The Framework releases is also not in
sync
with either Gear nor Plasma while these two modules heavily make use of
Framework
and contribute to Framework.
* We could have an unified LTS release including more than just Plasma. This is
something that distros have been asking for some time already because having
just Plasma receiving bug-fixes but not Framework nor the apps is not that
helpful.
* In term of promotion, it is very difficult to advertise the 3 releases because
combined we have an important release of either Gear, Plasma or Framework
every
few weeks. This is too frequent and often while a combined announcement would
have enough content to be published in a tech newspaper. When splitting the
content
accross 2 announcements (Gear and Plasma), we reduce the content per
announcement and this makes it less interesting for the journalists to write
about us. This doesn't come from me, this is that some journalists directly
told me.
* We won't have 3 different release teams but instead have a bigger one with a
bigger bus factor. We could also unify the tooling for doing this mass
releases
a bit.
I do understand that there was valid reasons for splitting KDE Software
Collection
for Plasma 5 but I don't think this worked out. These were as far as I know the
main arguments used for splitting the Software Collection.
* Trying to move away from "KDE" being recognized as the software instead of the
community. This unfortunately didn't really work out, everyone is still using
KDE to refer to the desktop. Even distros call their edition "KDE" and I
don't blame
them, it's difficult to find a better term than that as for example "Fedora KDE
Spin"
not only contains Plasma but also a lot of KDE apps. Splitting the releases
won't
help with that, we need to find a better approach or just let it go and
accept that
people will keep using KDE to describe the desktop/software.
* Better promotion of our apps outside of Plasma. This is a valid point but I
think
pursuing our current strategy of putting our apps in many app store to be
more
effective. We could also show the platforms support of each applications more
prominently in our releases announcements like we already do on apps.kde.org
(e.g. https://apps.kde.org/okular/). Generally Plasma releases fare a lot
better
in term of promotion than the gear announcements and showing the applications
on an unified announcement would likely help spread the words about our
applications
better.
* Helps with outside usage of our frameworks. These didn't get as much success
as we were hoping when splitting. I think having a stable branch for
Framework
might help but this is only a guess. It would be interesting to know of cases
where people considered using some Framework and to know why they decided
against or for it and if this proposal would helps or not.
In effect this proposal would mean:
* We do one major release every 4 months and then minor releases with a
frequency
based on the Fibonacci numbers as this releases cycle works very well for
Plasma. Naming could be either YY.MM or Major.Minor.Path. We could unify that
for one or the other one. Or let each component keep their current versioning
scheme depending whether we want to merge Plama and Gear as product or
keep it separate. I'm a bit undecided about this.
* "KDE Framework" will still exists as an entity and its ABI and API
compatibility requirement. Only change is the release frequency and the
introduction
of a stable branch in sync with the other components.
* Only have one release announcement on our website. We can call it Megarelease
6.XX like we did for Plasma 6/Gear 24.02 or find a better name. I would
avoid reusing
Software Collection first because the name is quite technical and second
because
these was already used in the past.
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.
Cheers,
Carl
