31 Mar
2012
31 Mar
'12
7:08 p.m.
On 03/29/2012 04:41 PM, Vincent Massol wrote:
Here's a summary email (as I understand it!).
Ok if I understand correctly, what you'd like to propose is:
============================================
* Distribute without legacy by default
+1.
* Provide a way for users to add the legacy modules if
they need them (details to be defined for how they can do this - a zip containing jars to
drop in WEB-INF/lib, installation from the EM, etc)
Currently, legacy-oldcore replaces oldcore, so it won't be quite enough
to just install legacy-oldcore on top of the default distribution. We
need one of:
- ensure that the classloader always uses the classes from
legacy-oldcore in favor of oldcore jar
- tell the extension manager to remove the oldcore jar when installing
legacy-oldcore, which means that an extra requirement is that XWiki has
write access to its own files on disk
- find a way to have legacy-oldcore extend, not override the oldcore
classes, which would be possible if we can inject the AspectJ
classloader and change the way our aspects are being compiled and used
The same is true for the other legacy-* jars.
* When we deprecate an API we keep it in the main
modules (i.e. non-legacy modules) for a while. You're suggesting till the next major
version, i.e. a full Release Cycle (which is 1.2 years). This is the big difference with
now where we move to the legacy modules ASAP because we want to be sure that no code we
have uses the deprecated APIs. By keeping them in our codebase we wouldn't benefit
from this nice "feature". So we'd need a solution for that.
We could have two levels of legacy, one that is packaged in the default
distribution, and one that is optional.
* We never remove code from legacy modules ? (I think
you mentioned you' d be for removing but I haven't really understood the strategy
to do so)
+1 for removing, as you propose below.
Personally I'd prefer the following:
==========================
* Distribute without legacy by default
* Make it very easy for a user to add the legacy modules by providing a distribution
containing the legacy modules that is clearly visible in the download page (but less
visible that the distribution without legacy modules)
I'd rather not provide such a distribution. We already have too many
packages that the user has to chose from.
* Continue to move deprecated APIs to legacy modules
*ASAP* (i.e. as soon as our code is clean and doesn't use the newly deprecated APIs)
+1.
* Never remove from the legacy modules by default but
when we really need to do so (for some technical reason for example), do it on a case by
case basis and send a VOTE to do so
+1.
This would ensure that:
* New users very quickly use the newest APIs (they won't even see the old APIs).
* Older users are not broken
* When someone upgrades he can easily try using the new distribution without legacy and
if it breaks some of his code he can either fix his code or add the legacy modules
--
Sergiu Dumitriu
http://purl.org/net/sergiu/