avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Avalon Versions
Date Mon, 12 Jul 2004 09:14:10 GMT
Leo Sutic wrote:

> All,
> I've been following the latest threads, and just thought I'd jump in
> with two small comments.
> = 4.2 vs. 5 =
> Some have said that "of course 4.2 is incompatible with 4.1, you don't
> expect to use nio in a Java 1.3 environment, or a 2.3 servlet in a 2.2
> environment, do you?".
> Which is correct. If the minor version number increases, you can
> expect backwards compatibility for clients, but of course not for
> providers. But we're all in the business of developing providers.
> Which is why versioning in Avalon-land is perceived a bit different.
> A minor version change in framework is, for example, if you add a
> method to ExceptionUtils. The general opinion, as I remember it, is
> that a component-container contract change is a *major* version
> change. The fact that Serviceable/ServiceManager was a minor change
> should be written up as an exception.

I don't see why the addition of Serviceable/ServiceManager is any 
different to the addition of a method to ExceptionUtils.  In both cases 
source and binary compatibility are maintained but consumers of the new 
methods/classes are locking into a higher minor version.

> Above all, since contract changes impact container developers, they
> should be made in consensus with the most important container
> developers (Merlin team, Excalibur, Cocoon, etc.)

The decisions should be made with the concensus of the Avalon community.

> Since there is no reasonable way of fixing the underspecification of
> the 4.x versions without altering the framework, I think Niclas,
> Stephen et al should switch to Avalon *5*, and just start cutting
> cruft left, right and center. 

I think this is mixing politic with technical issues.  Technically 
speaking if we were to doing something like removal of selectors - that 
would justify a major version bump because it represents a incompatible 
change.  On the other hand the resolution of the underspecification 
issue can go a long way through minor version increments.

Personally I prefer the approach of nailing down missing information on 
4.X and getting out a 4.3 with a lot more semantic detail and 
deprecation of methods classes that we do not consider to be within 5.0. 
  This approach ensures that a 4.X to 5.X migration is managed process 
based on a consistent with a well understood versioning doctrine.  The 
alternative "leap" to 5.0 smells like a fork as opposed to a managed 

Cheers, Steve.


| Magic by Merlin                       |
| Production by Avalon                  |
|                                       |
| http://avalon.apache.org              |

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

View raw message