Niclas Hedhman wrote:
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) ??
Look, I'm just trying to see what common ground can be built, what the various interested parties are concerned with and find acceptable.
My initial concern was not so much with versioning but the resistence to put older 4.1 documents back online somewhere. In other words, document this change in the specification more explicitly and have some place where users can find the older spec information.
Personally, I'm rather easy going. I don't really care if it's called Avalon Framework 4.2 or 4.3 or 5 or XP. It appears to me that moving to Avalon Framework 5.x would resolve a lot of issues still hiding in the corners of Avalon and that we could finally put these things to rest.
It is not uncommon for projects to occasionally do a major version jump. Slackware Linux went from 4.0 to 7.0 something in one release. No one died. It wasn't for "technical" reasons only. Sometimes a version jump like that just makes sense.
jaaron
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]