Proposed adjustments to our release cycles

Ingo Klöcker kloecker at
Mon Jun 25 20:01:01 BST 2012

On Sunday 17 June 2012, Cornelius Schumacher wrote:
> 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.

And the Linux kernel developers combine this fast release cycle with 
long-term maintenance for some versions of the kernel. So, it's a win-
win situation! (Bingo! ;-) )

Quite frankly, IMHO long-term maintenance is something people should pay 
for (from the customer perspective) resp. be paid for (from the 
developer perspective) because it's not really fun work, definitely a 
lot less fun than feature development. Consequently, long-term 
maintenance should be done by entities who are offering professional 
support contracts, like distributors. And, guess what, distributors are 
already do this.

Also, this change would probably open opportunities for some of the more 
adventurous among us who always wanted to create a business around KDE. 
If the community stops doing long-term maintenance although there is 
demand for it, then this could be your chance to take over and make a 
living out of it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the kde-core-devel mailing list