Proposed adjustments to our release cycles
Sebastian Kügler
sebas at kde.org
Mon Jun 18 09:53:36 UTC 2012
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
More information about the release-team
mailing list