Nicola Ken Barozzi wrote:
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?
Honestly - I think its a bad thing to do. Deprecation is something that can be formally applied at a Java source file level and inforomally defined on other artificats (configs, etc). I would prefer this sort of thing to be managed at the CVS level in conjuntion with appropriate build procedures. If you tag something in CVS as a 1_X branch, then under that a 1_1 branch, and things get deprecated - when you do the 2_X branch - that's the point where the deprecated content dissapears. By introducing a xxx/classic and xxx/compat your basically moving the notion of branching out of CVS and into the file structure. Clearly things in the file structure tend to be easier to manage - but at the same time I think it has a bunch of hidden problems. Test cases in one example, but what about configurations, property files, etc. At the end of the day I think that this comes down to better management of CVS tags and synchronizing builds against tagged content.
But keep in mind that I'm not a CVS expert - I'm just expressing an observation!
:-)
Eeek - lots of little things pop up because not all of the implications have been considered.
Yeah, that's why it's a proposal. ;-)
I understand what your aiming at - just not convinced about the approach ;-) Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
