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.
Yes, I'm still experimenting with Cocoon, but I find it *very* interesting.
Take logkit as an example. There is a src/java and a source/compat. You cannot build one with the other.
Ahhh, ok. Yes, this is kinda wierd.
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.
Yes, I mean this :-)
However - in doing this you implicitly complicate you structure and while probably not significant in itself, if your looking at automating tools for building on a project like Avalon then its a significant point. Its significant because it is suggesting that any Avalon project could include a src/compat directory that needs to be included in the compile targets.Ant is an automated too :-)
If we use the same dir structure for all projects, we just need a single build.xml and import it in all the project builds, it's not a problem.
Taking this further - does the same policy apply to test cases?
Good point. What do you think?
Eeek - lots of little things pop up because not all of the implications have been considered.
Yeah, that's why it's a proposal. ;-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
