Can someone please translate this into a simpler form of English for me? I got lost.
Stephen McConnell wrote:
Berin Loritsch wrote:
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.
The avalon-framework 4 contact is a binary contract that represents a set of interfaces and classes dealing primarily with lifecycle artifacts and lifecycle delivery mechanisms. The 4.0 version was basically the less-than-friendly Component based model. The 4.1.3 version introduced the service package and opened up Avalon to the rest of the world. The 4.2 release follows the trend established by 4.1.3 in lowering framework dependence while delivering better build integrity and runtime functionality.
It was its own project and very jealously guarded for good reason.
Another possible interpretation is that it was very jealously guarded because competing camps could not come to agreements on anything else. If that interpretation has any merit - one could anticipate a vibrant and exciting development of the framework within and beyond the framework 4 context taking into consideration - even embracing other essential ingredients in the overall specification of a robust, reliable and portable component model.
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.
Yep - your in that place because the assertion is true.
This is the main point of
contention.
You need to clarify this. You have stated that the semantics backing the framework released to-date is insufficient. Presumably your referring to the overall specs related to 4.0, 4.1, 4.1.1, 4.1.2, 4.1.3 and 4.2.0 (not to mention a few other minor releases along the way).
Are you saying that the Avalon Community may neither claim now deliver backward compatibility as it moves forward? I would consider that to be an unwarranted restriction to the development of the framework - and I'm confident you agree with me.
The thing is that these things crept in not because of evolution to the framework but because of evolution of the containers.
So long as semantics at the level of the framework are undocumented and/or vague representations - a vacuum exists. Within that vacuum the Avalon Community is delivering a reference implementation. That reference implementation will inevitably fill in that vacuum.
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.
IMO - absolutely not. You are calling for a termination of the A4 development effort. You assuming that other minds cannot deal with improvement while maintaining compatibility. I fundamentally disagree with this assertion.
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.
This has nothing to do with the avalon-framework binary interface and the recognized rules concerning when and if you bump major and minor versions.
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.
And in the process mislead people about the evolution of the framework. Sorry - but your going to have to come up with a better *technical* argument than that.
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.
Where is the fundamental difference?
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.
As is the case with the avalon contract.
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.
And that was intended to facilitate collaboration, mutual respect and all of the other nice warn and fluffy feelings?
;-)
That's my two cents.
How about rethinking the scenario with the presumption that the Avalon community cares more about a complete component specifications than the framework in isolation - but the framework is an important part of that equation but not the complete equation. Consider also that the minds applied to the problems of evolution and value proposition delivery may perhaps be able to deliver more than has ever been archived in the past simply because the political barriers of the past exist only in the dustbins of history.
Cheers, Stephen.
--
"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]
