Change release schedule 4.2 and schedule for 4.3

[Sebastian Kügler]

For what it's worth, Aaron describes quite accurately what I have in mind (but 
which I wasn't really able to communicate effectively to everyone), so thanks 
for plugging into my brain and channeling the mess nicely into k-c-d :)

On Tuesday 09 September 2008 19:47:30 Aaron J. Seigo wrote:
> * Feature development happens in "hot" branches; let's call them Spring
> branches (new growth =)
>
> * Spring branches are merged when features are "ready" into a Summer
> branch. devel that doesn't require its own branch (small scope changes)
> happens in this merge branch as well. development may continue in Summer
> regardless of what's going on. anyone can create a Spring branch at any
> time, new development can happen in Summer at any time; this combination
> replaces the need for playground/.
>
> * Summer goes through rapid cycles of "1-2 weeks of devel and Spring
> merges, pause, up to one week of stabilization or until we're happy with
> it" at which point it merges into KDE's mainline, or "Autumn", branch. this
> is actually pretty close to what we already do in the middle parts of the
> feature devel part of a cycle.
>
> * Autumn branch should be in a relatively good situation due to the Summer
> cycle. it won't be perfect, but it'll be better than Spring or Summer
> branches. all other KDE developers would likely be using the Autumn branch,
> and would be at most 2-3 weeks behind Plasma developers, though usually
> less; this means bugs they notice are likely to still be useful to the
> Plasma team. as nearly all Plasma devel is done by people who contribute
> regularly to Plasma and would therefore be following the Summer branch,
> loss of patches due to small lag would be near-zero.
>
> * When KDE branches for release (call this the Winter branch), we will put
> an extra focus on bug fixing as we normally do but feature development can
> continue in Spring and Summer. bug fixes in Summer will be merge into
> Winter, just as we backport fixes now from trunk to 4.1 only a bit more
> aggressively pre-release (betas and RCs).

[...]

> any of the above could change in the future, and that may shift things yet
> again for us. at least with the "always Summer" approach we could shift
> back to how things are now really quite easily, while we are simply stuck
> with the current system no matter what.
-- 
sebas

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080910/4ca31d12/attachment.sig>