Change release schedule 4.2 and schedule for 4.3

[Jordi Polo]

BTW, I also give my +1 to what Aaron has stated in his mails.


On Wed, Sep 10, 2008 at 6:07 PM, Sebastian Kügler <sebas at kde.org> wrote:

> 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
>
>


-- 
Jordi Polo Carres
NLP laboratory - NAIST
http://www.bahasara.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080910/b5de1a71/attachment.htm>