Proposal unify back our release schedules

[Nate Graham]

Ok, so happily I actually see quite a bit of agreement here, regardless 
of what else we do.

1. Fibonacci bugfix releases are good, and we could benefit from having 
Gear adopt these.

2. Severing implicit dependencies is a good idea. Shared libraries in 
Gear are especially problematic and could benefit from being moved to 
Frameworks.

3. Fast frameworks releases in some capacity are a benefit and we don't 
want to lose this.


All in agreement? If so, that would be amazing.

---

Now, let's say we make Gear use Plasma's current release schedule by 
syncing up the feature releases and adopting the Fibonacci bugfix 
releases. If we don't end up changing Plasma's own release schedule then 
we already make our promo store more coherent by letting the marketing 
team do three big glossy announcements of user-facing products a year, 
rather than being stretched thin for 6. Even if we make Plasma go down 
to 2 releases a year, then we have two synced Gear+Plasma 
"mega-releases" and 2 independent Gear releases--down from 6 to 4. Both 
of these options would improve the promo story IMO.

---

Moving on, the biggest points of contention I see revolve around 
Frameworks. Personally I want to push back a bit on the idea of 
developing an app against released frameworks. This is only realistic if 
you use a rolling release distro and are okay with waiting a month to 
use the new Frameworks code. For users looking to contribute with common 
discrete-release distros, it is not at all realistic as many Frameworks 
consumers require versions newer than what those users have on their 
system, so they have to build some Frameworks anyway (note: not all of 
them; kdesrc-build/kde-builder are smart enough not to do unnecessary 
work). The older the distro's packages, the more likely this is to be.

Furthermore, because Frameworks has time-based releases and no beta 
releases, in practice the QA is provided by developers living on master. 
If KDE developers deliberately avoid this, they're not participating in 
QA. There are of course other ways to improve Frameworks' QA as well, 
but continuing to encourage KDE developers to use distro-packaged 
Frameworks goes against the larger goal: we can't QA software versions 
we're not using.

While 12 releases a year of Frameworks feels fast, it's actually not. 
Gear also has 12 releases a year: 3 feature releases and 9 bugfix 
releases. And Plasma currently gets 18: 3 feature releases and 15 bugfix 
releases. The lack of bugfix releases is notable. With Plasma if a major 
bug is discovered a day after the release (which is common) I can ship a 
fix within a week, whereas for Frameworks, it takes a month. This is not 
a theoretical problem; it has happened many times over the years.

To me it has always felt strange that the product that benefits most 
from stability gets 4 times as many yearly feature releases as Gear and 
Plasma, but no bugfix releases at all. And there have been many 
occasions oven the years where new features in Frameworks could have 
benefited from a bit more QA time in master before final release.

In this sense I find Frameworks' release schedule to be both too fast 
and too slow: too fast for new features and too slow for bugfixes. 
Shouldn't the product with the strongest stability guarantee ship 
bugfixes at least as fast as Plasma?

If Frameworks got a feature release every 2 or 3 months and a guaranteed 
bugfix release one week after each feature release, IMO the result would 
be much better. We could ship fixes for important bugs faster, 
developers would be more incentivized to live on master and therefore 
provide their own QA, the period of time during which issues with new 
features could be caught before release would be doubled or tripled, and 
we could even still have 12 total releases per year.

---

Thus, if we make Gear's release cycle identical to Plasma's to get it 
faster bugfixes, and then we also lengthen Frameworks' release cycle so 
it gets the bugfix releases it could benefit from while slowing down its 
feature releases to improve QA, then the result looks a lot like Carl's 
proposal, and that's ultimately why it looks appealing to me.

This doesn't preclude breaking implicit dependencies and relocating 
software into groups/release vehicles more suited for them. I don't find 
the argument convincing that we ought to deal with pain to make this 
happen. IMO we should make decisions about the final form we want, not 
based on what we think will torture us into getting there. :)

Nate