Proposed adjustments to our release cycles

[Cornelius Schumacher]

On Sunday 17 June 2012 Inge Wallin wrote:
> 
> The reasoning behind the move towards shorter release cycles is exactly the
> opposite of how large organizations reason when they select software.
> Remember the outcry when Firefox went to its current way of releasing.
> When Brazil rolls out KDE to 24 million users, they don't want to have to
> update that every 2-4 months.

That's the challenge of our industry. Web apps are on release cycles of hours 
or even minutes. Browsers are following suit and are on much shorter cycles 
than they used to be, the Linux kernel is also making it a point to be on a 
very fast release cycle. They all do it, because there are obvious benefits in 
getting new features and bug fixes out to users earlier.

But users still want to have stability, and the classical approach, especially 
for enterprises, is to minimize change. This obviously creates a conflict. But 
there are ways to address this.

I think shorter release cycles are doable, if we make sure that we have 
automated test infrastructure in place, which minimizes regressions, and the 
channels how our software gets to the end user are set up to handle a release 
process of increased agility. The first we have in our hands, the second is 
something where we need to team up with distributions.

-- 
Cornelius Schumacher <schumacher at kde.org>