Proposal: New refined release cycle [WAS: Re: release plan for 2.2.2]

Dan Meltzer parallelgrapefruit at gmail.com
Wed Nov 11 14:18:56 CET 2009


On Wed, Nov 11, 2009 at 4:10 AM, Mark Kretschmann <kretschmann at kde.org> wrote:
> On Tue, Nov 10, 2009 at 10:50 PM, Lydia Pintscher <lydia at kde.org> wrote:
>> Heya :)
>>
>> I sat down to make the release plan proposal for 2.2.2. It hasn't been
>> easy since there is Christmas and Co and New Years involved this time.
>> I tried my best...
>
> Thanks. What I'd like to propose is a refined cycle for our upcoming
> releases. A cycle that takes our experiences (some good, some bad)
> from the 2.2.1 release into account. The scheme is simple, but I am
> optimistic that it could improve things a bit. Here goes:
>
>
> "The 5 + 3 Release Cycle"
>
> In effect it's similar to the current 6 weeks cycle. The difference:
> After 5 weeks, we make a limited "preview" release. You could call it
> a beta, or tech preview, or something similar. This release only needs
> to be announced on our mailing lists, without the usual big promotion
> push.
>
> Then, after this beta, we spend another 3 weeks on processing the user
> feedback and refining our product according to the feedback. Which
> mostly means one thing: Fixing bugs.
>
> Ultimately, this scheme prolongs our current cycle (6 weeks) by two
> weeks, making it a 2-months cycle. My impression is that this could
> work out quite well. After trying this refined cycle, we could again
> evaluate it, and then see if we must refine it further

As we discussed on IRC, I disagree with this, and heres why:

1) Much of the new feature development already happens outside of
trunk, and therefore is ongoing during freezes anyways, this allows
features to be dumped  in early in the release cycle and already gives
them more time for testing.

2) We could roll a beta @ string freeze, which gives us three weeks
for testing anyways in a 6 week cycle.

3)  The longer we take between releases, the longer it takes to get
fixes out.  One of the appeals of such a short cycle is that we don't
have to feel obligated to make each one absolutely perfect, and be
tempted to delay a release for a OMGMUSTHAVE feature, because we will
soon be releasing another version.  The longer we take between
versions, the more tempting it is to delay a version to get another
cool new feature in.

Dan,
>
> --
> Mark Kretschmann
> Amarok Developer
> www.kde.org - amarok.kde.org
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>


More information about the Amarok-devel mailing list