3.5 months for the planned cycle seems a bit two long especially when
you think it would be reasonable to bump it for something important.
I personally would like to see 2 months planned, so if it runs long
we are closer to 3 months instead of 4.
-dain
On Jun 9, 2006, at 4:22 PM, Aaron Mulder wrote:
On 6/9/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
Sounds good. Can you put together a time table representation of
this idea? It would help me understand the nuances.
Hypothentically speaking, here's a 3.5-month schedule for 1.2:
June 12: 1.1 released
- select release manager for 1.2
- set goals for 1.2
July 1: 1.2-M1 released
July 21: 1.2-M2 released
August 14: 1.2-beta1 released
Sep 1: 1.2-beta2 released, no new features
Sep 14: 1.2-rc1 released, no non-critical bugs
- 1.3-SNAPSHOT branch created
Sep 21: 1.2-rc2 released
Sep 27: vote on 1.2-rc2 as 1.2
Oct 1: release 1.2
Though perhaps we could move the feature/bug freezes down one release.
And, of course, if a lot of problems were discovered in, say, 1.2-rc1
then perhaps we'd introduce an extra 1-2 week rc into the plan. What
do you think?
Thanks,
Aaron
