Niclas,
But it WOULD mean that since Avalon specs must be tightenend, Fortress would have to comply with these for component interoperability according to such new component specifications required to reach there. That would not be optional.
Exactly. That is what I have been saying, that you cannot simply put Fortress in maintenance mode and forget about it. Fortress needs to support a common set of meta tags to allow even more component reuse, for new components that'll be written to the new specs. But, the fact remains, that for backwards compatibility Fortress will always need to support the current set of tags (and, therefore, the associated semantics) it supports.
But I think you guys need to get off the high horse that says "once we have voted, that's it, we can never go back". There's too much dependence on the vote about the current meta package, the current repository, and the one container strategy. Please do not ignore the original authors of framework, ECM, Phoenix, Fortress: almost to a person they seem to say they would like something different. It is time to revisit all of those in the context of one framework and multiple containers.
So get active on the codebase - get voted in as a committer after demonstrating commitment and ability to work with the community - and get yourself onto the PMC - and from there influence the decisions that are made. In the meantime - decisions have been made and Avalon is moving forward. The question is not if we moving forward - the question is how to deal with the pragmatics of migration and user transitioning.
Cheers, Stephen.
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
