No, this isn't about how easy it is to bring back the removed
method/class. It's about WHEN the removal happens and what choices do
downstream users have.
Of course users have the possibility of bringing back the old
plugins/modules, but shouldn't there be at least a period of notice that
lets them know something is being replaced by something better and allow
them time to migrate their code? Isn't it bad if we just force them to
make a choice between:
- migrate custom code in a very short time
- delay the upgrade until they can migrate custom code
- have duplicated incompatible features because they have the new code
in the standard distribution, and the old code that they rely on
Plus, it's not fair to favor individual methods. If a method is moved to
the legacy module, it is still maintained, since it is compiled at every
build. A retired module, however, will bitrot undisturbed since it isn't
compiled on newer versions of the code. So retired modules are likely to
have a shorter "forever" working period. And sometimes we're even
retiring a suddenly broken module because we don't feel like putting in
the extra effort to update the old code.
And again, we're removing actively used code, but keeping methods that
we're 100% sure NOBODY is using.
On 11/22/2013 11:44 AM, Thomas Mortagne wrote:
You are mixing very different things here, removing a
single method
from a class break everything that use that method, period. You can't
do anything to use your old extension except rewrite it. So no it's
really not the same thing...
As for this specific use case, we are talking about a module that
never been part of XE except in 5.2 and any extension properly written
have it in dependency so the fact that it's in XE or not does not
really change much for those.
On Fri, Nov 22, 2013 at 5:11 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
> Why doesn't anybody listen to me when I say that it's wrong to just move
> out APIs without a proper deprecation period? It's not OK to ever remove
> individual methods that are 100% unused, but it's OK to completely
> remove a whole plugin that is still being actively used without even a
> single release worth of notice...
>
> On 11/22/2013 05:40 AM, Marius Dumitru Florea wrote:
>> Guys, I didn't pay enough attention to this topic (thus my +0) but
>> what we did is very bad! I used myself $services.wikimanager in lots
>> of places and I'm sure others have used it also (especially since we
>> moved to virtual mode on by default) so we cannot simply remove an API
>> like this. This is not different than removing a method or a class
>> from a public API (which would be caught by CLIRR). We need to apply
>> the same deprecation strategy: mark $services.wikimanager as
>> deprecated, move to legacy, log warning messages when it is used,
>> update all places in platform where it is currently used, etc.
>>
>> I just found out that the Wiki search facet isn't displayed as I
>> advertised it in the release notes of 5.3M2
>>
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki53M2#HSea…
>> because the Wiki Manager API has been removed
>>
https://github.com/xwiki/xwiki-enterprise/commit/b8fcbc7267ff587807698b4afd…
>> after I closed my issue
http://jira.xwiki.org/browse/XWIKI-9613 ..
>>
>> We need ensure that the public API of Wiki Manager (e.g. the script
>> service) is still available. It can wrap the new API or it can do what
>> it currently does but it has to remain available.
>>
>> Thanks,
>> Marius
>>
>> On Thu, Nov 14, 2013 at 5:56 PM, Marius Dumitru Florea
>> <mariusdumitru.florea(a)xwiki.com> wrote:
>>> +0
>>>
>>> Thanks,
>>> Marius
>>>
>>> On Wed, Nov 13, 2013 at 6:45 PM, Guillaume "Louis-Marie" Delhumeau
>>> <gdelhumeau(a)xwiki.com> wrote:
>>>> Hi devs.
>>>>
>>>> Thomas has merged my pull request for the new wiki API. I'm happy!
>>>>
>>>> Now, xwiki-platform-wiki-manager and xwiki-platform-workspaces are
>>>> obsoletes. We should delete them or move them to xwiki-contrib.
>>>>
>>>> Here is my +1 for the move!