[xwiki-devs] [VOTE] Introduce xwiki-legacy for backward compatibility code
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 Jerome.
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. This means we'll have 2 places: - aspects - xwiki-legacy We'll need to document this on dev.xwiki.org. Thanks -Vincent
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
On Fri, Dec 10, 2010 at 15:40, 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.
This means we'll have 2 places: - aspects - xwiki-legacy
We'll need to document this on dev.xwiki.org.
IMO you actually propose the opposite of what you want. Having a xwiki-legacy module will really help to have "all compatibility stuff in one place". Currently we put aspect in the module where the class containing the deprected method is. We could have aspect (at least the one that does not need to be in original class module) in this xwiki-legacy module.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+1 for me. I favor moving away from aspectj where possible because it is fundamentally not java and the more languages an application is written in, the more complex it becomes. Caleb On 12/10/2010 10:47 AM, Thomas Mortagne wrote:
On Fri, Dec 10, 2010 at 15:40, 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.
This means we'll have 2 places: - aspects - xwiki-legacy
We'll need to document this on dev.xwiki.org.
IMO you actually propose the opposite of what you want. Having a xwiki-legacy module will really help to have "all compatibility stuff in one place". Currently we put aspect in the module where the class containing the deprected method is. We could have aspect (at least the one that does not need to be in original class module) in this xwiki-legacy module.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (4)
-
Caleb James DeLisle -
Jerome Velociter -
Thomas Mortagne -
Vincent Massol