Proposed adjustments to our release cycles

[David Jarvie]

On Mon, June 18, 2012 5:36 am, Martin Gräßlin wrote:
> On Monday 18 June 2012 00:26:13 Albert Astals Cid wrote:
>> My concerns:
>>
>>  * Uncertainity on the "current release state". We have people that don't
>> know the current state of the release and commit new features or new
>> strings when we are frozen, and that's with just one release schedule, i
>> can imagine the mess with N different release schedules
> "Always summer in trunk". As long as releases are not created from the
> master
> branch it should be fine. On the other hand nobody should commit without a
> review anyway, so just commit and push without proper communication with
> the core developer group is so wrong in the first place

This may apply to large projects, but KDE contains many smaller
applications which don't have large teams - they may only have one or two
people - able to independently review commits.

New features always carry extra risk of bugs and side effects, even if
they are carefully reviewed and tested. If we did feature releases more
often, it's difficult to believe that for many KDE components it wouldn't
result in a less stable state on average. The current 6 months release
cycle seems a sensible stabilisation period for released software. More
frequent releases run the danger of upsetting users more, which is
something we don't need.

>>  * The difficulty of coding for N releases. Since the releases an not
>> aligned anymore, you have to maintain code and #ifdefs for new features
>> that depend on new versions of parts X of the stack that may or might
>> not be used by people compiling the application. We've have some bad
>> experiences with "expected versions on the stack" so i hope you're
>> understanding this is not a theoretical scenario.
> Also here: proper Jenkins support. CI needs to scream at you if you commit
> something which does not compile.

Proper Jenkins support would be a minimum requirement before we started
releasing different components at different intervals. As Albert says,
this has already caused problems even when we release all of KDE SC
together.

However, simply ensuring that everything compiles is not all - different
versions of software components can functionally break things even if they
compile cleanly. This has been seen on occasion with Qt in the past, and
if we extend it to releasing different parts of kdelibs or kdepimlibs at
different intervals, this would exacerbate the potential risks.

For application developers dealing with bug reports, this is a really
difficult problem - it's already the case that a particular distro can
sometimes produce a bug which doesn't occur on other distros, and which
the developer using another distro can't reproduce and investigate. So
from an application developer's point of view, the fewer variants the
better. I'd rather see a rule that we keep to a uniform release schedule,
but perhaps allow individual ad-hoc exceptions if there is a really good
reason.

-- 
David Jarvie.
KDE developer.
KAlarm author - http://www.astrojar.org.uk/kalarm