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 infamousComponent 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
