10 Dec
2010
10 Dec
'10
3:49 p.m.
On Fri, Dec 10, 2010 at 3:40 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Dec 10, 2010, at 3:31 PM, Jerome Velociter wrote:
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.
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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs