Change Strategy (was Re: [VOTE] Instrument package into Framework namespace)

[Berin Loritsch <bl...@apache.org>]

Stefano Mazzocchi wrote:
> Leo Simons wrote:
> 
>> Leo Sutic wrote:
>>
>>>  1. The interfaces from the instrument package should move into the
>>>     org.apache.avalon.framework namespace.
>>
>>
>>
>> +1
> 
> 
> Maybe there will be one day when avalon packages will be rock solid and 
> won't change every 6 months.
> 
> Or one day cocoon will finally pass a Gump run without having avalon 
> dependencies broken.
> 
> Or one day I'll run out of patience as I did with Tomcat and remove 
> dependencies to the bear minimum.
> 
> Just keep in mind that everytime you feel you are seeking elegance and 
> order, you are, in fact, increasing the enthropy of the system anyway.

Stefano, can you please just come right out and say what you mean?
You are a member of the Avalon community so a simple -1 with an
explanation might be better than this "One day" crap.

You have only had perceived problems with Avalon Framework--IOW, no
change in Framework (the core jar you are using) has made Cocoon
cease to work.  Instrument is a new feature, that grew up in Excalibur.
The question now is whether to support the Instrument interfaces in
Framework, or keep it a part of Excalibur.

It is obvious you are against this.  Why?  Adding functionality to
Framework does not break Cocoon.  What it does is make us have to
handle legacy in the InstrumentManager.  That may be reason enough
not to do the change.  We are trying balance many things here.

THe dependency tree for some of the Avalon packages is potentially
circular, or very complex.  The proposal solves one of the causes
of the unnecessary complexity.  Granted, it is something that is
beyond *just* components, so we need to balance that fact with
incorporating Instrument into Framework.

Also keep in mind that as we learn, it affects what we percieve
Avalon to be.  Managing that change is a difficult task.  I welcome
any input from you as to how best to change.

Constant major version changes are really bad.  Noone complains about
bug fixes.  But what about refining the contracts?  Can you help us
all to understand what a decent change strategy is?

I thought we were doing an exemplary job of managing change at the
Framework level.  Please enlighten me how we can manage the balance
between too much change and stagnation.  I really would like to know.


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

Re: Change Strategy (was Re: [VOTE] Instrument package into Framework namespace)

[Leo Simons <le...@apache.org>]

Noel J. Bergman wrote:
> If you want an example, fine, but the specifics aren't as important as the
> approach.  One example of classes that are either removed or intended to be
> removed are the file repositories that Peter Donald (surname to qualify the
> overloaded reference) asked James to pull into our module because they
> weren't (and wouldn't be) supported by Avalon.  As an instance, it is no big
> deal.  We're happy to support them.  As a philosophy, it points to caution
> that you had better be prepared to support things before you make them part
> of your release.

Noel,

policywise, these classes (in cornerstone) are unreleased alpha code. So 
the example is flawed (then again, almost all examples are contrived by 
definition ;).

cheers,

- Leo



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

RE: Change Strategy (was Re: [VOTE] Instrument package into Framework namespace)

["Noel J. Bergman" <no...@devtech.com>]

Berin,

You asked for comments on change strategy.  I wasn't addressing a particular
case, e.g., Instrument packaging, in my reply to you.  I was giving a broad
overview of thoughts on what is and is not OK to do.

If you want an example, fine, but the specifics aren't as important as the
approach.  One example of classes that are either removed or intended to be
removed are the file repositories that Peter Donald (surname to qualify the
overloaded reference) asked James to pull into our module because they
weren't (and wouldn't be) supported by Avalon.  As an instance, it is no big
deal.  We're happy to support them.  As a philosophy, it points to caution
that you had better be prepared to support things before you make them part
of your release.

Likewise, I wasn't saying that you wouldn't properly handle migrating from
an Avalon package to a Commons package.  I was just outlining some issues
related to a Change Strategy, as you had asked.

	--- Noel


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

Re: Change Strategy (was Re: [VOTE] Instrument package into Framework namespace)

[Berin Loritsch <bl...@apache.org>]

Noel J. Bergman wrote:
>>Please enlighten me how we can manage the balance
>>between too much change and stagnation.
> 
> 
> My $0.02 (you can lookup the exchange rate if you care ;-)) is that
> interfaces do not change in incompatible ways within a major release number.
> It is OK to add, but not to change or remove.  And Avalon must be careful
> about things that it adds if Avalon isn't sure that they are going to stay.
> I will accept change in nightly builds, but once the Community votes to
> release the class, it'd better be prepared to support it long term.

This particular vote was to add.  We finally decided against it though.


>>>From that perspective, Avalon has both changed interfaces (the infamous
> Component issue), and entire sets of classes are either removed or under
> discussion.  Those should have required a major version rev, and a supported
> branch using the older interfaces.

The Component is still supported--just deprecated.  Which classes are
removed?  I am not aware of a case for this.


> What percentage of developers using Avalon do you believe follow discussions
> here?  Avalon can't just take a local vote to remove things that people may
> depend upon.

Well we weren't voting to remove anything in this instance.


> Now, let's consider something like replacing an Avalon package with a
> Commons package.  That could be viewed as a good thing to do.  The way to do
> it would be to deprecate the existing classes with comments telling us what
> the specific code is that replaces the deprecated code.  And the deprecated
> classes could be rewritten as a wrapper around the new package.
> 

So far, we have done this.  We will continue to do this as we move
forward and remove support for a large number of utility libraries that
need a new home.


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

RE: Change Strategy (was Re: [VOTE] Instrument package into Framework namespace)

["Noel J. Bergman" <no...@devtech.com>]

> Please enlighten me how we can manage the balance
> between too much change and stagnation.

My $0.02 (you can lookup the exchange rate if you care ;-)) is that
interfaces do not change in incompatible ways within a major release number.
It is OK to add, but not to change or remove.  And Avalon must be careful
about things that it adds if Avalon isn't sure that they are going to stay.
I will accept change in nightly builds, but once the Community votes to
release the class, it'd better be prepared to support it long term.

>From that perspective, Avalon has both changed interfaces (the infamous
Component issue), and entire sets of classes are either removed or under
discussion.  Those should have required a major version rev, and a supported
branch using the older interfaces.

What percentage of developers using Avalon do you believe follow discussions
here?  Avalon can't just take a local vote to remove things that people may
depend upon.

Now, let's consider something like replacing an Avalon package with a
Commons package.  That could be viewed as a good thing to do.  The way to do
it would be to deprecate the existing classes with comments telling us what
the specific code is that replaces the deprecated code.  And the deprecated
classes could be rewritten as a wrapper around the new package.

	--- Noel


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