J Aaron Farr wrote:
Niclas Hedhman wrote:
Is there anything else that has really been brought to the table?
Problem is a general clash of two mindsets:
Case #1 (pre-merlin 3.3)
Avalon specification = Avalon Framework
Case #2 (post-merlin 3.3)
Avalon specification = Framework + Meta + Composition + ...
While the transition between #1 and #2 may have only resulted in relatively minor changes to the Avalon framework (in terms of actual code), it has meant a major change to the specification, or Avalon platform or whatever you want to call it.
My gosh!
So, are you insinuating that the 'issue' is that a vendor container would need to say it is "Avalon Framework 4.x compliant" instead of a more wider term "Avalon 4 compliant" (which in my book doesn't even exist) or the much stricter "Avalon compliant" with or without a version attached (which is not ready to be launched yet) ??
Moving to Avalon 5 now, would just re-introduce the same problems all over again, and we would soon be on Avalon 6.
The current set is not complete coverage, and hence Avalon 5 would be full of holes, that we can't patch for the same reasons as now being argued over.
It is so much easier to require the Fortress, ECM, Loom, what-not to declare that they are "Avalon Framework 4 compliant" and that "Avalon compliant" and "Avalon 4 compliant" are not terms that exists. Let us evolve the missing pieces in parallel until Avalon 5 is more ready.
We could even issue a 'sticker' with the text on it, for people to feel more acknowledged, what is basically what LSD was requesting a few months back.
Cheers Niclas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
