Re: class-mobility between packages
On Fri, 5 Dec 2003, Stephen Colebourne wrote: 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. I think we should be trying harder than that. While we may not *need* to always maintain backward compatiablity with unreleased code, in the sense that we haven't promised it to anyone, we should strive to maintain compatiablity anyway. To do otherwise is to harm our early adopters, and to do that is to harm the project itself. 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 -- - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: class-mobility between packages
From: Rodney Waldhoff [EMAIL PROTECTED] On Fri, 5 Dec 2003, Stephen Colebourne wrote: 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. I think we should be trying harder than that. While we may not *need* to always maintain backward compatiablity with unreleased code, in the sense that we haven't promised it to anyone, we should strive to maintain compatiablity anyway. To do otherwise is to harm our early adopters, and to do that is to harm the project itself. Although initially I was opposed to this concept re unreleased code, I am now more of a supporter. Currently [collections] contains a lot of code that is deprecated solely for the purpose of nightly builds and a future snapshot. The idea being that it is removed once the ibiblio snapshot has occurred. This seem to produce a reasonable balance of flexibilty for code development with protection for users (and is particularly necessary given the time since the last collections release) Stephen 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 -- - Rod http://radio.weblogs.com/0122027/ - 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]
class-mobility between packages
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]
Re: class-mobility between packages
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]
