Stephen McConnell wrote:
Nicola Ken Barozzi wrote:
Peter Donald wrote:
On Sat, 1 Feb 2003 01:18, Berin Loritsch wrote:
+1. Maybe we can release put some kind of compat.jar in with the
distribution that contains this class?
I don't think its necessary. That *deprecated* class has been there
from almost the beginning. If people are still using it, shame on
them!
It should be safe to remove it after 1.5 years don't you think?
I would prefer us to maintain compatability in released code.
Especially when there is no real reason to break it.
Peter, this is what deprecation is all about, no?
Keep the stuff in for others to have time to change, then remove it.
Removing deprecated classes between major versions is a safe bet.
Between point versions it's a possibility.
Between fixes it's an error.
I'd suggest the following as a guideline:
- deprecating classes results in @deprecated being added
- in the next minor point release, they are moved to a
deprecated source tree for the component that is compiled
*after* the main ones, so that we are sure that /we/ do not
rely on those.
- in the major releases the classes can be removed with a vote.
Thoughts?
Hi Nicola:
I think the notion of "moving" depreciated classes needs more cooking.
Take logkit as an example. There is a src/java and a source/compat.
You cannot build one with the other. If on the other hand you were
talking about moving a class source to a deprecated set of sources - AND
- the main sources could be built without it - i.e. independently - then
this would more sense.
I can make it happen so that LogKit does not do this, and passes its
test cases.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
