On Fri, Dec 10, 2010 at 3:40 PM, Vincent Massol <[email protected]> wrote:
On Dec 10, 2010, at 3:31 PM, Jerome Velociter wrote:
Hi,
As suggested by Thomas in the thread relative to renaming document events (see http://xwiki.markmail.org/thread/62a3yaxiuosx4f6o ), I would like to introduce a new module, xwiki-legacy, to host backward compatibility code for modules. Rule would be that of course nothing should ever depend on xwiki-legacy. It will also help developers that relies on XWiki modules to upgrade to new code when we deprecate things, since as soon as they upgrade their dependency, they will not be able to build unless they fix the deprecated calls (It would not be the case if each module would host its backward-compatibility code).
First use case would be for renamed events. A listener in xwiki-legacy would listen to the new document events, and notify the old corresponding ones.
WDYT ?
I'm +1
I'm +0 because I prefer to have all compatibility stuff in one place only and we already have a place for that: in our aspects. Note that it's possible to put java classes in aspects AFAIR.
You would prefer code in aspects in their respective modules ? The strategy described by Thomas has the advantage to force people to upgrade to new APIs since they cannot build unless they fix their code (or depend on xwiki-legacy, but who would do that ? :)). If you keep the backward compatibility in each module, you don't have that. So in the end I think it's good, even though there will be two places indeed (we cannot get rid of aspects either since there is compatibility code that could not be written easily but with aspects). Jerome.
This means we'll have 2 places: - aspects - xwiki-legacy
We'll need to document this on dev.xwiki.org.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs