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 transition.
Cheers, Steve.
--
|---------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
