18 Jan
2016
18 Jan
'16
12:56 p.m.
Hi Paul,
On 18 Jan 2016 at 12:16:23, Paul Libbrecht (paul@hoplahup.net(mailto:paul@hoplahup.net))
wrote:
vincent(a)massol.net wrote:
Yes, I meant that legacy jars should give the
feeling that one should
get rid of them.
Marking them with "legacy of version 5.3" (which would mean something
such as "abandadonned at 5.3" would let the installers be aware that the
software they run still needs legacy that is maybe 2 years old.
Sure but that’s already the case through the Deprecation uberspector. What we don’t define
ATM is an end date and we don’t do this because:
1) there’s no strong need to remove legacy (it doesn’t cost us much to keep it)
2) we don’t provide enough visibility to developers of apps inside XWiki about the
deprecated methods they need so it would be unfair to completely remove APIs when we’re
not even sure they’d have seen the warnings. Thus the idea is to capture all the warnings
and error that happen when rendering the content of a wiki page and to make them available
for example in the new notifications area so that users can click on the notification and
see the errors/warning and fix their code (we could make it visible only to advanced
users, etc). Side note: we need a different style for the notifications menu when there
are notifications inside it.
We’ve been wanting to implement 2) for a long time now (at least I’ve been wanting to ;)),
just didn’t get it to it yet.
Thanks
-Vincent
wonder if
this could not be better controlled so that installers can
> actively get rid of the legacy.
Our current strategy has been to keep legacy forever, see:
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBackwar…
Our idea was to start not bundling legacy jars by default but we need the EM to support
legacy jars first as otherwise users will see breakages when they install extensions
requiring legacy APIs.
Do you have a different idea? paul