axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Davis <>
Subject RE: managing change during the 1.0 release process
Date Mon, 23 Sep 2002 16:47:33 GMT

:-)  Of course not - the change that's at issue should not have been made
in the first place (w/o consulting the group at large) so this is just
fixing it (IMO).

Tom Jordahl <> on 09/23/2002 12:37:52 PM

Please respond to

To:    "''" <>
Subject:    RE: managing change during the 1.0 release process

So if we are to do this, the API would NOT change back to the 'way it was'
because we released rc1 with this functionality the way it is now.

BTW I agree with Sanjiva on this, fix only the bugs, reject everything

Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: Sanjiva Weerawarana []
Sent: Monday, September 23, 2002 12:32 PM
To: Axis Development List
Subject: managing change during the 1.0 release process

Hi Guys,

IMO everyone needs to constrain their changes at this stage if
there is to be any real hope of getting 1.0 out this year. In
stuff I've released, once something in RC stage *nothing* changes
except bug fixes. Changing user-level APIs is absolutely out, as
is changing any internal guts for "cleaner guts" purposes.

I think Rick's frustration is reasonable. Dims, I find it a bit
hard to accept the position that users should file test cases
for functionality they've gotten used to in a beta/RC stage that
they'd like to keep. The reason to go from alpha to beta is (and
was, even here) to signal to users that things are somewhat stable.

I suggest that we develop a precise list of what needs to be done
for 1.0 and do *nothing* but that. Reject EVERY other change. Yep,
that's pretty damn draconian, but that's the only way to get such
a big beast like Axis completed and out the door. This is especially
true for 1.0.

If all committers don't agree to this then I am not at all
confident this will get done in 2002.


View raw message