API stability

[Jeremy Boynes <jb...@apache.org>]

Recently the API for constructing GBeanInfo changed when the builder 
class was renamed from GBeanInfoFactory to GBeanInfoBuilder. I agree 
with the intent here but I would ask that in the future when we make 
such a large change we give more heads up to the community.

My concern here is that this class is fundamental enough that it is used 
in every GBean. Yes, the change fixed this for the project, but it will 
have been disruptive to any users out there who may have written their 
own GBeans. We broke their code for what is essentially a cosmetic 
change (a more fitting name for the class).

We cannot afford to gain the reputation that some projects' have: of 
changing APIs willy-nilly. People will end up writing code against 
Geronimo specific APIs and they need to have the confidence that there 
will be stability from one release to the next.

We are close enough to a final release now that we need to start 
considering this kind of impact during day-to-day development and use 
professional judgment on whether a change *should* be made and if so how.

For example, I believe this was a good change to make as it clarifies 
the purpose of that class. Given this is a fundamental API, it is of 
benefit to users to have this right in V1.0 so that we do not have a 
legacy issue forever. However, this is not a blocking issue and it is 
not critical enough that it needed to be made immediately and without 
notice.

Instead, I would have preferred if someone could have proposed this on 
the mailing list first and given users reasonable notice before actually 
making the change.

I realize that there could have been discussions of this privately or 
perhaps on IRC, but such discussions need to be mailed to the dev list 
so that the community as a whole gets involved.

--
Jeremy

Re: API stability

[Lyndon Samson <sa...@dodo.net.au>]

I've often through it would be nice to have a 'redirecting'
classloader in these sort of circumstances.

Have some rules/conditions which map from one fully qualified
classname to another.

So a simple case might be

Requested -> Actual
x.y.z.A   -> x.y.z.B

Perhaps you can allready get similar functionality ( and more ) with
AOP frameworks?

Potentially confusing, but also useful I think.

Either that or stub and deprecate the old fully qualified classnames.

cheers
lyndon

Re: API stability

[Aaron Mulder <am...@alumni.princeton.edu>]

	+1

On Sat, 30 Oct 2004, Jeremy Boynes wrote:
> Recently the API for constructing GBeanInfo changed when the builder 
> class was renamed from GBeanInfoFactory to GBeanInfoBuilder. I agree 
> with the intent here but I would ask that in the future when we make 
> such a large change we give more heads up to the community.
> 
> My concern here is that this class is fundamental enough that it is used 
> in every GBean. Yes, the change fixed this for the project, but it will 
> have been disruptive to any users out there who may have written their 
> own GBeans. We broke their code for what is essentially a cosmetic 
> change (a more fitting name for the class).
> 
> We cannot afford to gain the reputation that some projects' have: of 
> changing APIs willy-nilly. People will end up writing code against 
> Geronimo specific APIs and they need to have the confidence that there 
> will be stability from one release to the next.
> 
> We are close enough to a final release now that we need to start 
> considering this kind of impact during day-to-day development and use 
> professional judgment on whether a change *should* be made and if so how.
> 
> For example, I believe this was a good change to make as it clarifies 
> the purpose of that class. Given this is a fundamental API, it is of 
> benefit to users to have this right in V1.0 so that we do not have a 
> legacy issue forever. However, this is not a blocking issue and it is 
> not critical enough that it needed to be made immediately and without 
> notice.
> 
> Instead, I would have preferred if someone could have proposed this on 
> the mailing list first and given users reasonable notice before actually 
> making the change.
> 
> I realize that there could have been discussions of this privately or 
> perhaps on IRC, but such discussions need to be mailed to the dev list 
> so that the community as a whole gets involved.
> 
> --
> Jeremy
>