Nowadays, Fedora and (K)Ubuntu are mostly making new releases twice a year, with relatively predictable release schedules. (Unfortunately I don't know about OpenSuse release schedule).
Unfortunately, new KDE releases happen a little bit too late for them to be included in those distribution in time for the release. Thus the current version of KDE in both Fedora and Kubuntu is one release behind.
Maybe we should consider asking upstream KDE to shorten one release cycle (and then keep the 6 month schedule) to align them with a more distribution friendly cycle. This would benefit both upstream and downstream:
Another discussion thread on the topic: https://www.markshuttleworth.com/archives/tag/synchronization
Yeah, this has become a problem as of late. We missed Plasma 5.20 for Fedora 33 because of this. :cry:
@apol, what are your thoughts on this?
I'm totally in favor of this. I'm happy to chat with the folks who manage upstream's release schedule and see how to best fit them into Fedora's. It's worth noting, too, that Python changed their release schedule to be more predictable in part to make sure they can land in the earliest Fedora release. The more coordinated our releases, the better it is for both projects.
We have already changed or schedules in the past because of distros. I would encourage you to take part in Plasma kickstart meetings for each release and voice your opinions.
I would not expect the release cadence to change but adjusting is definitely on the table.
@apol is there a calendar which has the Plasma release kickoffs that @bcotton and I can subscribe to?
Yes. The idea would probably be to shorten one single release cycle for syncing and then keep the release cycle as is (every 6 months).
I don't think there is a calendar, the meeting is chosen soon after the last release is finalised (yesterday we had 5.21, @ngompa you were there during the second half).
Since we need to accommodate a wide range of people I'd recommend following the plasma mailing list. It's fairly low traffic: plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
There generally is a poll to decide when it's going to be to maximise attendance.
That could ve an ad-hoc discussion I guess we should have. Feel free to bring it up on the mailing list. I'll be happy to review the text beforehand if that helps.
If there's any way I can help support this as FPL, let me know!
Here's what it's looking right now for Plasma 5.21. https://community.kde.org/Schedules/Plasma_5#Future_releases
Yeah, so it looks like we'll have the same problem again with Plasma 5.23, so if we can tweak that release schedule, we can make sure that lands with Fedora 35.
(We are technically going to miss 5.22 for Fedora 34, but the window is too far anyway, so ehh...)
Metadata Update from @ngompa: - Issue set to the milestone: Fedora 35 (was: Future Release)
I see 2 options: - we can bring it up as the dates were literally just set with a sensible proposal - wait and address it for good when Plasma 6 is a thing (or we start moving development there, which will alter Plasma 5 development anyway). There's no ETA for that though.
Wait, does this mean that F33 will not receive KDE 5.20 at all? I thought the reason we didn't get 5.19 in F32 was because of a large QT version update.
We are going to get Plasma 5.20, it's just going to be a post-GA update. This is about aligning for GA releases.
WIP document: https://hackmd.io/jDNa611aTu-2u7PlK2Uu8w
https://mail.kde.org/pipermail/plasma-devel/2020-November/118890.html
So Plasma releases are 4 months aligned (not 6 months) and this will probably not change soon so I don't think we can do anything here.
Pushing for 3 months releases is still an option.
From a program management perspective, I'd feel pretty uncomfortable asking an upstream to cut off 25% of their development cycle. Of course, I'm not familiar with KDE's processes, so maybe it's not as much of an imposition at it seems from the outside.
I'd like to see their releases fit with the downstream distros' (particularly, but not exclusively Fedora Linux) schedules, but I'm not sure I have a better answer.
Okay, I have a different answer, perhaps not a better answer:
We ship whatever Plasma version is released at about our beta freeze. New releases are packaged as a module that users can switch to instead.
This seems like the exact sort of use case that modularity is intended for. It allows us to follow Fedora' guidelines by not introducing a new version but still gives folks who want that the opportunity to easily get it.
Metadata Update from @siosm: - Issue untagged with: meeting
I think nothing is going to really change here, so let's close this out for now. We can revisit this later if we want to.
Metadata Update from @ngompa: - Issue close_status updated to: Won't fix - Issue status updated to: Closed (was: Open)
Metadata Update from @ngompa: - Issue status updated to: Open (was: Closed)
Metadata Update from @ngompa: - Issue close_status updated to: Can't fix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.