Proposed adjustments to our release cycles

[Shaun Reich]

On Sat, Jun 16, 2012 at 9:44 PM, Inge Wallin <inge at lysator.liu.se> wrote:
> As far as I could understand from the above the main ideas are:
>  - Splitting the SC into 3 parts
>  - Shortening the release cycles significantly.
>
> It seems to me that a current trend in larger free software projects is to go

which projects? you pointed out firefox, which is shortening, and so
is chrome these days ;)

> If we shorten the release cycles (an idea
> which I am actually not that fond of) then could we also consider to have an
> LTS release now and then?

i see your point..

while continuously backporting to say.. 2 prior versions does incur a
good amount of overhead, i don't think it'd be *too* much of an issue
as it's pretty damn easy with git. i mean, you'd just be backporting
to 1 additional branch each time, 1 more than usual...

i'm definitely liking the "shorter releases" plan though, despite some
hiccups we'll encounter in implementation. having a release early,
often, and always stable is something i've always thought we needed.
it'd make it easier to run master without having your machine break in
new ways every 2 days.

-- 
Shaun Reich,
KDE Software Developer (kde.org)