On 11/13/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
We were using Woden M6 within Axis2. But I moved to Woden SNAPSHOT, because we were getting read to the upcoming interop event. I noticed some compilation errors in our Axis2 code, as two parameters were removed from the places I was using. I had no clue on how to correct this as those params were *just removed.*
Sure that is a problem and annoying for anyone coding to Woden. I hate it when this happens to me.
I agree that Woden devs must have complete freedom to change the API as and when they want to come up with the best possiblem API. I have no objections for that.
Cool
What I need is a deprecation mechanism, so that people who are actually using Woden has a clue on adapting to changes. For example, if the Foo class contained build() method, then Woden devs wanted to move that to Bar class, then 1. mark the Foo.build() as deprecated. Perhaps you might wanna call Bar.build() from that method. 2. Add a note in Foo.build() asking to move to Bar.method(). This process will allow Woden devs to change the APIs as and when you want. And at the same time, it will become easy for people like us to change according to the changes.
Agreed, as long as we document #2 in the deprecation warning then I think this will work for the majority of API changes we're likely to make. There may be times where deprecation can't work (or is hard to make work) - eg interface package rename. All I'm saying is this approach follows the 80/20 (or maybe even 90/10 :-)
If the Foo.build() was in M(i) release. And if the method change happened after it, then mark Foo.build() as deprecated in M(i+1) release and remove it in M(i+2) release.
in which case the removal could be in the first snapshot built towards the M(i+2) release - i.e. the first after the M(i+1) release.
I hope I made myself clear. We will be able to have more discussion during the upcoming interop as well.
What did you think to my post [1] about dated SNAPSHOTs providing some protection against API changes. This would then put you back in control over the level of Woden you use; rather than having Maven download the latest SNAPSHOT whenever you build and potentially destabilising your build. I think this in combination with the deprecation idea will provide you with the control over the level of Woden you use (in case an API change escapes our careful eye) and allow you to move over to new APIs at your own pace (with the time limit being the following Woden milestone). We could certainly put the deprecation into practice sooner rather than later. What does the rest of the list think? Should we vote? [1] http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200611.mbox/[EMAIL PROTECTED]
-- Chinthaka
Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
