release planning and 0.7

[Ivan Glushkov]

On 7/25/07, Vlad Skvortsov <vss at 73rus.com> wrote:
> Hi!
>
> I was thinking recently about our release planning -- I feel that the
> current model doesn't work too well. Let's face it -- we don't have
> enough resources which leads to *huge* gaps between releases and hurts
> both our users (waiting half a year for a minor feature?) and us (the
> projects looks as "stalled"). I would like to heal that situation by
> switching to kind of "sprint" model, when we try to deliver a release at
> least once a month. This way we'll all feel more rewarded, get more
> feedback and gain more visibility.
>
>  From now on, starting with release 0.7, I propose to plan the following
> way. For a release we choose a list of 10 issues, of which
> * 1 is a major/architectural change;
> * 3 are medium complexity;
> * 6 are minor/trivial changes.
>
> We will target a release (code freeze, in fact) in 4 weeks exactly. If
> by the end of this sprint at least 7 of the nominated issues get
> resolved, we roll out the release. Of course if all 10 get resolved
> earlier than the end of the sprint, we release earlier.
>
> Comments? Opinions? I'll come up with proposed nominated list for 0.7 by
> the weekend.

It's high time we started to use such "sprint" model!
We are making a lot of changes in each release, too much to my mind.
You say about release 0.7, but what about 0.6? Currently, we have 5
open issues on 0.6. Four of them are very simple, but "file
attachment" is a great one.

I'd like to look at 0.7-mustfix list!

Ivan