Carsten Ziegeler wrote:
The following idea came to my mind during the weekend. All the recent discussions about a new core/container etc. show that a possible future version of Cocoon will have a different component handling than we have now.
One major concern for me is compatibility. It would be bad if someone had to rewrite his complete application just to update from one version of Cocoon to another. I guess we all agree on this. Now reaching this goal can be done from two sides: a) The new version can have a compatibility layer. b) We can provide a smooth transition from version to version.
It would be ideal if we would have both. But with a compatibility layer people tend to just use it without migrating their app.
<snip/>
As long as the compatibility layer remains, I don't see what invites people to migrate to new features. Is it just because new features will be available? Then having them because of an updated old container or because of a newer one with a legacy layer isn't very different in this regard, except that new features are readily available in the second case.
That's why I'm in favor of adding a legacy layer to something new. I started the avalonization of Spring a few hours ago and the more I dig, the more the technical issues I felt I would hit disappear one after the other. I have to stop for now as I have some urgent work to do for tomorrow (a new training), but that's definitely the way I want to go instead of adding new features on top of an old thing.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
