It's not about the numbering system; it's about the August people like to bandy about.
Realistically, if we are going to have anything like a stable release in the August timeframe, we need to feature lock now, so that we can test and document what we already got. I'm not against the new API, and I'm not against making "large changes". I'm against waiting any longer before we decide whether we are going to make the changes or not. If people are not quite ready to roll out the new API, I'd also be very open to starting on the 2.1.x series as soon as we have a reasonable 2.0.x distribution. The hard, realistic question is whether people are ready to do the work now or six weeks from now. -Ted. On 7/24/06, Don Brown <[EMAIL PROTECTED]> wrote:
Now wait a minute - what happened to our alpha releases? In a more traditional scheme, you would have "2.0 alpha" and "2.0 alpha 1", which could contain basically anything you want. The clear alpha designation indicates that big changes are in progress and this is more of a milestone release to encourage development contributions. As we are going with this Tomcat/HTTPD-style system, I was under the impression that "2.0 alpha" would become "2.0.0 quality alpha" and could still contain anything we want. Therefore, 2.0.0 and 2.0.1 could have radically different content because both were judged alpha quality. Either we allow anything we want, including a new api, in the 2.0.x releases until a beta is declared, or we should move back to a more familiar release naming system. Development milestones are important and they shouldn't be eliminated. Don Ted Husted wrote: > On 7/23/06, Bob Lee <[EMAIL PROTECTED]> wrote: >> If we want to tag now, the new API will have to wait for 3.0. > > I think we are reaching the point where if we still want to make > "large changes" for 2.0, we need to make them now, or make them in > 2.1. AFAIC, we can open 2.1 as soon as we have a stable 2.0 > distribution. (Or as soon as someone volunteers to port the patches.) > > But, with my release manager hat on, I am saying that any "large > changes" slated for 2.0.x have to be committed by July 31, or be > postponed. > > -Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
