On Mon, Jul 17, 2017 at 3:03 PM, Vincent Massol <vincent(a)massol.net> wrote:
On 17 Jul 2017, at 13:42, Vincent Massol
<vincent(a)massol.net> wrote:
>
> On 17 Jul 2017, at 13:23, Ecaterina Moraru (Valica) <valicac(a)gmail.com>
wrote:
>
> On Sat, Jul 15, 2017 at 5:06 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>
>> Hi devs,
>>
>> Needs:
>> * We need some “Deprecated” macro category so that users understand
when
a
macro is deprecated and are less tempted to use it
To be honest I would prefer to not have 'Deprecated' macros at all.
I think you’re missing the use case and that’s why we still have the
Spaces Macro
in the Standard flavor (for example):
* Imagine you have an XWiki 6.x installed
* Now imagine you want to upgrade to 8.x
* If we remove deprecated macros then suddenly after you upgrade your
wiki you’ll
get several pages failing with some red errors telling you that
the macros are not available in your wiki.
It’s the same reason why there are deprecations in Java: to not break
users or
developers.
So yes we’ll be able to remove deprecated macros one day, when we judge
that
enough users have migrated to a recent versions and are no longer
using the deprecated macros.
I believe it’s still a bit too early for the Spaces macro for example
(it was used
by the Space Dashboard template for example). But it’s
possible that once we have 9.x be the LTS, we could think about removing it.
However there’ll always be use cases for deprecated macros.
FTR and the for the sake of being complete on this discussion, it’s
possible to do what you want Caty, but we would need to implement something
more complex:
* During upgrade, find out if there are macros used (by searching in the
wiki for example - but it’s not guaranteed we’ll find all places since the
macro usage could be generated by script) that are not bundled anymore and
if so propose in the DW UI a step to install them.
yes, interesting :) but as you said more work.
So, in this case, we should use just 1 category (not 2) - let's choose
'Deprecated'. This category should not be displayed in the Editor, but kept
for backwards compatibility. In the Macros Index, we will display it there
and also the macro will be findable with EM in the installed category.
Actually I think we need some more generic rule regarding this
'Deprecation' topic, since it applies also on Panels.
From an usage perspective the "(Legacy)" or
"Deprecated" wording on warning
boxes, increases more the attention I give
to that macro/panel instead of
doing the exact opposite.
Thanks,
Caty
Thanks
-Vincent
> If
> someone misses some macro he could install it from EM. We keep listing
the
Workspace
macro for such a long time. When are we going to remove it?
I agree that we could remove it now. We just need to decide if we go to
the extra
effort of moving it to contrib or just drop it (I’d be in favor
of just dropping it and wait for someone to ask for it - It’s still in the
SCM in the history if we need it one day).
Thanks
-Vincent
>
>
>> * We need to not show “Internal” macros by default to not “pollute” the
>> Macro list by default
>>
>> Proposal:
>> * When the “All Macros” is selected display all macros *except* those
from
>> 2 categories: “Deprecated” and
“Internal”.
>>
>
> Currently in 'Internal' I see just the 'Template' macro. For me
that's
> 'Development'.
>
> If it's internal and we don't want people to use it, why are we still
> displaying / bundling them?
>
> Thanks,
> Caty
>
>
>> * If the user needs/wants to use those macros, he’ll need to explicitly
>> select those categories.
>> * When we want to deprecate a Macro we move it from its category to the
>> “Deprecated” category, before removing it further in the future (when
is
to
>> be defined on an adhoc basis)
>>
>> Technical details:
>> * Change
https://github.com/xwiki-contrib/application-ckeditor/
>> blob/master/plugins/src/main/resources/xwiki-macro/
macroSelector.js#L144
>> to implement this new behavior
>>
>> WDYT?
>>
>> Thanks
>> -Vincent