Eoghan, On Thursday 26 April 2007 06:26, Glynn, Eoghan wrote: > Can you be explicit on the much more we'd have to lose by holding the > release until the outstanding issues are resolved?
Very simple: we've already pissed off some of our users by waiting this long. We NEED to get release artifacts into the maven repository ASAP so other projects can proceed with their releases. The main example is Yoko. 2 months ago, they asked for a release so they could do a release. We were unable to provide that to them. They ended up doing an "orb only" release that didn't include any CXF stuff at all. That is/was a major "lose" for our community as well as their community. They have again asked us for release artifacts. If we cannot provide them, they will again be forced into an "orb only" release. That is BAD for both projects. We need to be in a position to respond to such requests and help our users. Not force them into dropping CXF stuff from their releases. I don't know the current Yoko plans, but at one point they wanted a release by JavaOne. Let's look at the timeline. To do that, they need to call their vote by next Tuesday. (3 days vote internal, 3 days on [EMAIL PROTECTED]). Thus, our release needs to be done before that. The current vote will hopefully be done tomorrow afternoon internally at which point I can start the [EMAIL PROTECTED] vote. 3 days later is Monday, although due to the weekend, I should give it longer. We're already cutting it too close. > All other things being equal, it would seem more logical to me to just > fix up the issues. Yes, we need to fix the issues. I'm hoping to be able to get on a fairly frequent release cycle. I'm actually hoping for every 4-6 weeks. That should provide recent artifacts in the release repository for other projects to depend on/use. If we follow that schedule, it also allows users to expect and plan on when the next release will be. It's been almost 5 months since the last release. That's WAY too long. We should not force our users to depend on SNAPSHOT versions for very long. That's a recipe for disaster. We need frequent non-snapshots that the users can migrate to as their plans and schedules permit. > Could we get the best of both worlds by inviting feedback on a release > candidate, as opposed to a full release? Doesn't solve the Yoko problem. In anycase, to meet our diversity requirements and attract new users and developers, we need to get code out to them. This is the first step in that process. Dan > On specific issues, I'd like to see the Spring bean > createFromAPI/suffix made consistent before the release, as this is a > user-facing issue that will cause confusion and would be harder to > change (yet again) further down the line, when hopefully there'll be a > lot of users with config files in production. > > Cheers, > Eoghan > > > -----Original Message----- > > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > > Sent: 25 April 2007 19:12 > > To: [email protected] > > Subject: Re: [VOTE] Release CXF 2.0-incubator-RC > > > > I think we can update the STATUS/DISCLAIMER issues for our 2.0 > > final. > > > > I'm expecting that we still need to squash some bugs in this > > release - including things turned up by the TCK, 2 or 3 > > examples (although from what I understand they mostly work, > > just not with servlets?), and a few policy things. I think we > > have much more to lose though by not doing a release ASAP and > > not getting feedback then we do by waiting until all these > > things are resolved > > > > Cheers, > > - Dan > > > > On 4/25/07, Jim Jagielski <[EMAIL PROTECTED]> wrote: > > > +1 on the release by the way :) :) > > > > > > On Apr 25, 2007, at 10:55 AM, Jim Jagielski wrote: > > > > Looking over the distro-src: > > > > DISCLAIMER seems to lack newlines... > > > > STATUS is very out of date > > > > Build and test looks good (cannot recreate > > > > the exceptions Jim Ma sees) > > > > > > > > In the binary distro: > > > > Same DISCLAIMER note > > > > Again, build and test looks good. > > > > > > > > On Apr 24, 2007, at 2:50 PM, Daniel Kulp wrote: > > > >> This is a vote to release CXF 2.0-incubator-RC. This > > > > release is a > > > > > >> major step forward from M1. This release includes following new > > > >> features and enhancement: > > > >> * WS-policy framework > > > >> * WS-Security > > > >> * HTTP transport enhancements > > > >> * Aegis databinding support > > > >> * Configuration refactoring and improvement, > > > > including support of > > > > > >> Spring 2.0 config syntax > > > >> * Tooling (mainly wsdl2java, java2wsdl) refactoring and > > > >> improvements > > > >> * Many JAX-WS issues fixes (still not tck compliant yet) > > > >> * Many other JIRA issues and code cleanup > > > >> * MUCH MUCH more > > > >> > > > >> > > > >> The staging area is at: > > > >> http://people.apache.org/~dkulp/stage_cxf/2.0_incubator-RC_take > > > >>1/ > > > >> > > > >> The distros are in the "distro" directory. > > > >> The "maven" directory contains the stuff that will by > > > > pushed to the > > > > > >> m2-incubating-repository. > > > >> > > > >> This release is tagged at: > > > >> http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0- > > > >> incubator-RC/ > > > >> > > > >> > > > >> Here is my +1. The vote will be open here for 72 hours. > > > >> > > > >> -- > > > >> J. Daniel Kulp > > > >> Principal Engineer > > > >> IONA > > > >> P: 781-902-8727 C: 508-380-7194 > > > >> [EMAIL PROTECTED] > > > >> http://www.dankulp.com/blog > > > > -- > > Dan Diephouse > > Envoi Solutions > > http://envoisolutions.com | http://netzooid.com/blog -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
