Aaron,
I like the schedule below. From a 1.1 perspective I think we made several mistakes. We were
optimistic about our time, we were unclear about the content, we disrupted development for many
while only a few did the lion's share of the work (Dain and Jencks, has off for the rework). After
that we let the TCK stumble, etc.
From your outline below I think it matches what would follow as a significant release. I would
like to start a 1.1.1 branch right after we cut 1.1. For that release I want to address outstanding
JIRAs, usability and performance. Hopefully there will be a few others that are interested in
helping out there as well. I'll start another thread on that topic when we get 1.1 out the door.
I think the timeframe below seems a bit long but perhaps with some incremental 1.1.x releases it
might fill in the gaps nicely.
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
