The 'line' is the release. Once code is released we have a duty of backwards compatability to it. Thats not to say it will never move, but it can only do so by deprecating the original.
Some refactoring occurs because of history - collections was a bundle of collections written elsewhere rather than a dedicated, planned re-usable component. Collections 3.0 switches from bundle to planned, which does involve some deprecation moves. It should be much quiter after collections 3.0 (lang was much quiter after 2.0). Primitives was a special case in that code existed unreleased for so long that it became release-like. Hence care has been taken in how it has been moved. Stephen ----- Original Message ----- From: "Ash .." <[EMAIL PROTECTED]> > On observing some of the programming activity on this list, I find that > classes are moved around -- respectably speaking, refactored -- into other > packages quite generously. I would like to know what the general guidelines > to this are, especially I mean, where do you draw the line. And with special > view on backward-compatibility, what is the guiding principle here? > > I ask this is special relevance to lang, collections and primitives, but the > question applies to any others within the commons framework as well. > > Ash > > _________________________________________________________________ > Sign-up for a FREE BT Broadband connection today! > http://www.msn.co.uk/specials/btbroadband > > > --------------------------------------------------------------------- > 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]
