Robert, It's very important to remember that the mere fact we roll a release doesn't mean it will ever get past alpha. The overall average at Jakarta seems to be five or six alpha/beta releases to each stable release.
This will be the second point release in the 1.2.x series. It may be voted stable, or it may not. If changes to our dependencies are imminent, then we will be rolling another release before we even have a chance to vote on this one :) At this point, there is *nothing* more important that getting away from this mindset that a release is some type of traumatic event. We should be able to release on "any given Sunday", without all this brouhaha. The reason releases become traumatic is because we wait too long. By releasing this week, we will be in a much better position to release again after JavaOne, when these other matters are sorted out. On the other hand, if we don't release now, and let issues pile on top of issues, then it just all gets more complicated. We end up trying to fix too many things at once, and find ourselves waiting for too many dominoes to fall. Our resources are limited, and we can't stretch them too thin. Point releases should be weeks apart, not months. -Ted. On Mon, 07 Jun 2004 21:28:51 +0100, robert burrell donkin wrote: > the major worry for craig was the potential incompatibility with > new tomcat releases. > > since the community seems pretty keen on cutting validator and > struts releases whose dependencies which might not work properly in > the near future, so i suppose that i've done what i can and you > can't say i haven't done my best to warn you :) > > since the new releases should be binary compatible, it should be > possible for users to drop in a different selection of the more > modern libraries without these compatibility issues. maybe we could > head some of the user questions off by adding something to a page > somewhere or to the wiki. > > - robert > > > On 7 Jun 2004, at 15:48, Ted Husted wrote: > > >> We really should be making releases every few weeks anyway. So, >> we can roll a release now and again when the new dependencies >> become availability. >> >> I'm very much opposed to making sweeping dependency changes * >> before* releasing what we already have. Been there, done that, >> didn't like it, and affirmed it wouldn't happen again. :) >> >> -Ted. > > > -------------------------------------------------------------------- > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
