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