On Jun 8, 2006, at 5:44 PM, Aaron Mulder wrote:
I propose for 1.2 we drive it more by time than by features. That is, we lay out a schedule including builds every 2-3 weeks, initially milestone builds, becoming beta and RC builds. We try to get people to test and provide feedback on the builds as we go, and we expect that we'll have some issues early to mid-way through the process but have clear dates for feature freeze, no bugs fixes except blockers, branch for the next release, etc. We may have to adjust the schedule depending on what develops, but at least we'll know what we're targeting at all times. Then we'll have to huddle after the 1.2 release and decide whether this was an improvement over the 1.1 process or not, and decide how to go for 1.3/2.0.
Sounds good. Can you put together a time table representation of this idea? It would help me understand the nuances.
Thanks, -dain
