Given the inability to deprecate smoothly I suggest we take the hit and
put <blink> tags around this change in the release notes.
Maybe we should put a section titled "Backwards Incompatible Changes" (and
make sure we explain why they are backwards incompatible).
Big +1 for making both the changes proposed!
Sanjiva.
Glen Daniels wrote:
Hi Asankha:
We can certainly add deprecated methods for the setters and the
constructors, but not for getName() (since it would only differ by
return type). That being the case, I figured just take the hit now
rather than only having the set half of the API continue to work.
Let me know if you think we should add the deprecated setters, though!
--Glen
Asankha C. Perera wrote:
Glen
I agree its good overall, but I am a bit concerned about a public API
change if its without deprecation of the previous methods. Synapse can
upgrade our code - but there may be other projects/code outside that
may get broken. Just a concern..
asankha
How about
public void engageModule(String modName) {
engageModule(new QName(modName));
}
Funny you should ask... How about I just do the same thing with
Module names (Stringify them) right now and be done with it?
---------------------------------------------------------------------
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]
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
