Hi, Mart, and all.
>> To avoid such situations in the future, I suggest to make a release plan,
>> or at least a freeze date announced months before the freeze itself for
>> the next releases.
Yes, we need this. To my mind, this freeze date can't reasonably be stated
right after the big feature freeze date (we are not in the profesional world
where we know how much time people can spend on work).
So, the "months before the freeze itself" solution, let's say "about 2 months"
(to be discussed) is good for me.
> What about a release shedule like the one below. I made it up very fast, so
> the times in there might not be optimal. I think it better to first talk about
> the structure of it.
> ============
> = Release data 1.4.0 is called A.
> * A + 1 month: big future list freeze (after that, no big features may be
> added to the list of big features that will be in 2.0).
> After A + 1month we need a meeting to discuss the elements on that list. Every
> item needs a majority to stay on the list (not really different then the
> current voting system we use in case of conflicts).
> = We name the time that those bugs are reasanable implemented time B.
Yes. But we can't accurately forsee B too long before it really comes.
That's not a pb, BTW.
> * B + 2 weeks: total feature freeze (no small features are allowed anymore).
To my mind, a bit short. 1 month, 2 months ?
> * B + 3 weeks: first alpha released.
Do we want alpha releases for users ? Or do we keep them inside the dev team,
making the "alpha" step only a virtual one, without real file release on SF.net
(only may be a SVN tag + test work for the team) ?
> = Time C is the time when all the important open bugs are resolved before beta
> 1. At time B + 2 weeks, time C is more exactly descripted.
> * C: release beta 1.
> * C + 2 weeks: release beta 2 (unless there is no need for it).
> * C + 4 weeks: beta 3 if neccesairy.
> = Time D: time when all open bugs sheduled for 2.0.0 are fixed.
> * D: release of 2.0.0 rc 1 (can be skipped)
> * Release candidates can be repeated until one is stable enough.
> = Time E is the time of the main release.
> * E + 4 weeks: release of 2.0.1.
> * E + 10 weeks: release of 2.0.2.
To my mind, we should make bug fix releases _only_ if really necessary,
that is when really bad bugs happens and no workaround exists.
Then, we wan't forsee such events ... so, no need for a schedule here ...
Cheers,
Jean-Philippe.
|