avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Change Strategy (was Re: [VOTE] Instrument package into Framework namespace)
Date Mon, 24 Feb 2003 22:11:09 GMT
> 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


Mime
View raw message