Folks, Fact #1: WSCOMMONS-131 is fixed in SVN. Fact #2: We've started a VOTE for releasing Axiom 1.2.1 [1]. Plan is to do the release this week.
What's the ruckus all about? (Please don't make me all the emails :) thanks, dims [1] http://mail-archives.apache.org/mod_mbox/ws-commons-dev/200611.mbox/[EMAIL PROTECTED] On 11/28/06, Jim Marino <[EMAIL PROTECTED]> wrote:
> On the chat we identified 3 options that we could consider for > how to deal with this problem. > > 1. release what we have > 2. release without axis > 3. wait until axis is fixed > > Other options were discussed but did not get much support. For the > three that I have listed above (as summarized by Meeraj on the chat), > there are some variations and refinements. I have tried to summarize > the main points that were made in the chat in the paragraphs below. > > For option 1, we could mitigate the problem by explaining it in our > M2 release documentation, and we could release an update to the > Axis2 binding (a mandatory patch) that fixes the problem as soon as > new axis2 and axiom releases are available. As long as there is no > breaking change to axiom-api before the new release is available, > this means at all times we would have a combination that works. > The downside is that it looks bad to release something that we know > is broken (or will become broken in the future), even though there > is a patch available to fix the brokenness. > I would characterize the downside in different terms, similar to what Jeremy has mentioned: we would be putting out a release that ultimately will not work. Having a patch doesn't really fix the problem. That said, it seems we are trying to make a decision without enough facts. I propose we find the answers to several questions (or at least get more information) before attempting to make a decision on the best way of going. How big of an impact are the required changes for Axis? And, what is the likely timeframe of these changes, days, a week, a month, etc.? If discover that it is a few weeks then we can step back and ask why we are considering a release then patch strategy in the first place. There seems to be an assumption that we have to release now as opposed to waiting or taking the time to do a proper fix. Why is this the case since if someone needs access to the code they can just check it out from the repo and build? If it is a convenience for applications developers, then having them wait just a little longer (they can also just check the code out if they are in a rush) is really not that much of a problem given that they should not be using Tuscany or SCA for any project that is intended for production. If we find the fix will require months or an undetermined length of time (which does not seem likely), why not refactor for modularity in trunk, assess its impact and then decide if we want to move the changes to to M2 and cut a modular release that addresses the problem? In the meantime, we have the advantage of assessing progress on the Axis fix. It may take a couple of weeks to do this but is it really critical we get something out this week? Producing a release that we know is broken seems like we are marching to an artificial deadline without enough facts. Jim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
