Fwd: Re: Fwd: KDE Frameworks Release Cycle

Alexander Neundorf neundorf at kde.org
Wed Apr 30 19:52:58 UTC 2014

On Wednesday, April 30, 2014 15:51:56 Àlex Fiestas wrote:
> On Wednesday 30 April 2014 13:44:50 Raymond Wooninck wrote:
> > > So, you will not simply update to 4.14.X but instead do cherry-picking
> > > of
> > > the bug fixes? Because that would be the same with Frameworks.
> > 
> > You got that one wrong :)  We push the 4.14.x release as a full
> > maintenance
> > update. So if 13.2 is shipped with 4.14.0, then 4.14.1 is pushed as
> > maintenance update as soon as it becomes available.  This is no longer
> > possible with Frameworks.
> It is, you (as in opensuse) just have to get over the drama of having small
> features in on each release.
> Let's try to analyze a bit why some distros have this panic to new versions
> containing features (when it comes to KDE).
> For the longest amount of time in KDE4 has been releasing as a whole doing a
> big release every 6 months. This had the following impact of how things
> were developed:
> -People would develop super big features, some times even new apps.
> -People would push last minutes features to avoid the freeze (if you don't
> get in then you had to wait up to 8 months for next release).
> -People would merge things that are not ready because if something is wrong
> a bit was not a big deal (you had months to amend it).
> -Each release contained a lot of code changed.

Just my POV as a developer: I disagree strongly.
Having a stable branch where everybody (users, distributors, developers) can 
be sure only safe bugfixes went in, is a good thing.
It can make quite sure regressions are avoided. This is the big thing: a bug 
fix (patch) release should at all costs not introduce regressions.
For a bug-fix branch, sometimes a hack is acceptable if it safely in some way 
avoids the bug, and makes sure it doesn't introduce regressions.
The proper fix for a bug may be more involved, and may have some risk of 
introducing unexpected regressions.

So, IMO, this is not "drama of having small features". This is the serious 
wish to avoid being yelled at by users if anything broke in a bug fix release.


More information about the release-team mailing list