Proposed adjustments to our release cycles

[Martin Gräßlin]

On Monday 18 June 2012 00:26:13 Albert Astals Cid wrote:
> My concerns:
> 
>  * Need more people to do the tarball packaging/releasing (since if you
> propose to release that often you can't expect the same person to be doing
> packages almost weekly or byweekly given the release dates won't probably
> align)
I would say we need proper Jenkins support for that. It must be as simple as 
clicking one button to have the tarball fall out of the CI system and already 
know whether it compiles or not.
> 
>  * 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
> 
>  * 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.

Cheers
Martin
-------------- 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: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120618/73bd2897/attachment.sig>