avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject Re: Avalon Versions
Date Mon, 12 Jul 2004 13:59:47 GMT
Stephen McConnell wrote:
> Leo Sutic wrote:
>> 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.

I disagree here, and I will put the main disagreement as plainly as I
possibly can:

Up until Avalon 4 the _only_ point of required compliance was the set of
contracts stated and enforced by the Framework.  It was its own project
and very jealously guarded for good reason.  Now we are in a place where
some people assert that not only framework but a whole host of other
things are required for an Avalon component.  This is the main point of
contention.  The thing is that these things crept in not because of
evolution to the framework but because of evolution of the containers.

I think we need to come to grips and realize that there will always be
incompatibilities with Avalon 4 containers.  Period.  Anything more than
framework compliance is a container specific feature.

If you want to make the rest of the "component platform" an official 
part of defining an avalon component the best and cleanest solution is 
to bump the major version as an obvious signal that the current suite
of APIs is Avalon 5.  No need for drama, no need to call people names
or argue over what we are going to call methods.  Just say that Avalon 5
is all of this stuff, because Avalon 4 just wasn't able to deliver on a
bunch of promises.

I can't think of a better way to say it.  As long as the 4 version
number is in use that is my take on it.  Since everyone brings up the
analogy of Java2 version 5 and Servlet 2.x, it is comparing apples and
oranges.  There is a fundamental disagreement on what makes an Avalon
component and the minimum of what is necessary to make things 
compatible.  The core basics of Java2 version 5 and Servlet 2.x are
essentially the same, so there isn't as much of a need for a clean

If you want room to migrate "naturally" to a 5.0 because you are still
experimenting, then I would be ok with a 4.5 is all of this stuff and
this version of framework and anything before that is framework only.
That way there is a sufficient enough jump in version number while you
can grow your TCK (which I personally will be astounded when and *if*
it ever shows up) and other improvements to the Avalon platform.

That's my two cents.  I am offering what I consider a sane and decent
resolution to the process that will answer the concerns of all the folks
who are using Avalon _framework_ and move on.  As of right now, I 
consider all the other stuff to be Merlin container specific and it 
seems as if the same care in preserving the framework is not being kept. 
  The version bump will help answer a lot of uneasyness.  Oh and for an 
example of version jumping, just check out Microsoft.  When it went to 
version 7 in the office suite, all the products had the same version 
number, even if the last one was 2 or 3.  I don't think that would be 
too out of the question.

It is a non-technical answer to a non-technical problem.


"Programming today is a race between software engineers striving to 
build bigger and better idiot-proof programs, and the Universe trying to 
produce bigger and better idiots. So far, the Universe is winning."
                 - Rich Cook

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

View raw message