Proposed adjustments to our release cycles

[Maksim Orlovich]

>
> Starting with KDE Frameworks 5, we will release Frameworks, Workspaces and
> Applications each with their own release cycles. Each of these releases
> would
> be a set of tarballs of the latest stable versions of the application (or
> codebase in more general).
> As an example, Frameworks could release updates every 2 months, while our
> application collection is updated monthly. New iterations of the workspaces

<snip>
How do you reconcile this proposal with our current troubles in 4.8.4,
where you need certain particular combinations of two sets of
libraries for things not to blow up? Your proposal increases the
number of combinations in wide use, and hence makes testability worse.
(And yes, we already have this problem with Qt --- where most new
versions cause at least some noticeable bugs in KDE making updating Qt
before a newer KDE release sometimes a net negative).

> More specifically for the Workspaces, we would like to release all
> workspaces
> at the same time.
>
> This model would
>
> * Allow components to skip releases if they need to take a longer
> development
>   cycle
> * encourage developers to have an always releasable master
> * put more emphasis on continuous integration and other automated testing

What continuous integration and automated testing? How many apps have any?