[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-release-team
Subject: Re: Proposed adjustments to our release cycles
From: Sebastian =?ISO-8859-1?Q?K=FCgler?= <sebas () kde ! org>
Date: 2012-06-18 9:53:36
Message-ID: 4397534.1fORzPq0D8 () miro
[Download RAW message or body]
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
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic