class-mobility between packages

["Ash .." <eq...@hotmail.com>]

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: class-mobility between packages

[Stephen Colebourne <sc...@btopenworld.com>]

From: "Rodney Waldhoff" <rw...@apache.org>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: class-mobility between packages

[Rodney Waldhoff <rw...@apache.org>]

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: class-mobility between packages

[Stephen Colebourne <sc...@btopenworld.com>]

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 .." <eq...@hotmail.com>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org