Proposed adjustments to our release cycles

[Sebastian Kügler]

On Monday, June 18, 2012 00:26:13 Albert Astals Cid wrote:
>  * 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)
> 
>  * 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
> 
>  * 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.
> 
> What's your opinion on these issues?

Especially on the last issue, I think it's important that we create a proper 
platform definition and communicate that upfront. That definition would 
include dependencies (package + version) of our own Frameworks that are 
required, and of their dependencies, including for example X, Mesa, QtJSon, 
libmysqlclient, etc.

I suppose most of this information can be extracted from CMake, even.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9