Hi Edy and all,
On 24 May 2017, at 00:14, Eduard Moraru
<enygma2002(a)gmail.com> wrote:
On Tue, May 23, 2017 at 7:55 PM, Vincent Massol <vincent(a)massol.net> wrote:
On 23 May 2017, at 18:37, Eduard Moraru
<enygma2002(a)gmail.com> wrote:
Hi,
My only point to this discussion is that, as Thomas (I believe) already
mentioned, since 7.2 spaces are deprecated. We can consider that the time
in between (7.2-9.5) was more than enough for anyone still using spaces
to
migrate to Nested Pages (and the NP-based
alternatives), this includes us
doing the "deprecation" approach and keeping those pages.
I agree that it’s been a long time. I actually put this information in the
jira issue:
https://jira.xwiki.org/browse/XWIKI-13101
"
Specifically:
* Panels.SpaceDocs was deprecated in XWiki 7.3M2 (XWIKI-12599)
* Panels.Spaces was deprecated in XWiki 7.4.2/8.0M2 (XWIKI-12829)
* Main.Spaces and Main.SpaceIndex are also deprecated by the move to
nested pages and the removal of the Space notion from the UI
“
Note that we never deprecated officially Main.Spaces and Main.SpaceIndex.
Now that the time
has past, I believe it is safe to remove those pages and move forward.
Otherwise, if we plan to support them even further, IMO, we`ll end up in
a
ridiculous situation, supporting code that has no
value and that nobody
should be using anymore.
Note that this is what we’re doing for APIs so I assume you consider pages
to not be as important as APIs (or at least those pages).
I think you`ve missed by point completely :)
I consider those pages deprecated by default (because their behavior is no
longer doing what it was originally supposed to do) starting with 7.2. Our
deprecation strategy says to leave them on about 2 major releases.
On this point:
1/ We currently don’t have a deprecation strategy for pages and we have no way to let the
user know that a page has been deprecated and that he should stop using it (unlike the
java code where we have the @Deprecated annotation). So it would be nice if we could
define a mechanism IMO.
2/ On the java side we don’t remove deprecated code ever, we move code to Legacy modules.
I’m offline ATM but if the doc says we remove deprecated APIs then it’s in contradiction
with the backward compat strategy and we need to fix it. I’ll check it out when I connect
again.
For 1/, I guess there are several ways of doing it. Some wild ideas:
* A - Allow extensions to mark deprecated pages and offer an Admin UI showing lists of
deprecated pages
* B - Introduce a XWiki.DeprecatedClass xclass (with a “since” xproperty and a
“description” one to explain what the user should use) and add it an xobjecg of it when we
deprecate pages and have an Admin UI showing lists of deprecated pages. We could also
imagine that once we implement page rendering logs inside the wiki (as opposed to in the
container logs) we could issue a warning when a deprecated page is accessed.
We are
now working towards 9.5. I consider that enough time in order to both
respect our deprecation strategy and be able to move forward (i.e.
dropping/removing/killing them with fire :) ).
:)
Yes, we *are* doing the same thing with API, so I
don`t see why we should
add yet *another* deprecation layer (i.e. 2 major releases starting from
now), hence the "ridiculous situation" I`ve mentioned). Yes, it was never
"deprecated officially", but so what if they stopped doing what they were
supposed to do?
Those pages are not completely broken BTW. They’re just displaying non optimal things (ie
lists instead of trees).
Note: I don`t have anything against moving them to
some dark basement (i.e.
contrib repo) either, just that I would not invest more in the process more
than writing one phrase in the readme file. AFAIK, we did not do this in
the past (i.e. retiring code without properly documenting it), however,
previously retired projects had a lifecycle of their own and basic value,
so that`s why I`m in favor of just discarding this now unused/not working
code.
Ok that’s an important point to me. In the past we’ve been pretty good at API level but
quite bad at UI level. We regularly broke UIs here and there and I believe we need to
improve. I find this very important since that’s users see immediately when they upgrade.
IMO we should be 100% perfect to not break anything or cause WTF moments when user
upgrade. At least we should strive for that.
So while we can agree we’re spending a lot of time on this topic which some consider like
a no-brainer, I’m being careful and ensuring that we discuss it because I feel we’ve not
been that good in the past and I’d really that we offer our users good upgrade experience.
I have the feeling this is an important new goal that we should work towards.
Do we agree on this? :)
Thanks
-Vincent
Anyway, that`s my view of the subject.
Thanks,
Eduard
>> So I`m +1 for removing them.
>
> Remove them altogether or do the hard work of creating a special extension
> for them and releasing that extension?
>
> Personally if we do the "remove from platform” (which seems to be the
> direction so far) then I’d drop them altogether because I don’t think
> anyone would notice that those pages still exist somewhere and we don’t
> have any automatic way of conveying that information to the user (except
> release notes but we know this isn’t foolproof and we could link to the
> last version of those pages in the SCM or the last version of the XARs
> containing them if someone really needs to get them back.
>
> Thanks
> -Vincent
>
>>
>> Thanks,
>> Eduard
>>
>> On Tue, May 23, 2017 at 6:33 PM, Vincent Massol <vincent(a)massol.net>
> wrote:
>>
>>>
>>>> On 23 May 2017, at 17:03, Marius Dumitru Florea <
>>> mariusdumitru.florea(a)xwiki.com> wrote:
>>>>
>>>> On Tue, May 23, 2017 at 5:07 PM, Vincent Massol
<vincent(a)massol.net>
>>> wrote:
>>>>
>>>>>
>>>>>> On 23 May 2017, at 16:01, Marius Dumitru Florea <
>>>>> mariusdumitru.florea(a)xwiki.com> wrote:
>>>>>>
>>>>>> On Tue, May 23, 2017 at 4:25 PM, Vincent Massol
<vincent(a)massol.net>
>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>> On 23 May 2017, at 15:22, Marius Dumitru Florea <
>>>>>>> mariusdumitru.florea(a)xwiki.com> wrote:
>>>>>>>>
>>>>>>>> On Mon, May 22, 2017 at 4:34 PM, Thomas Mortagne <
>>>>>>> thomas.mortagne(a)xwiki.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I would be more in favor of moving them to some
extension than can
>>> be
>>>>>>>>> easily installed if really needed.
>>>>>>>>>
>>>>>>>>
>>>>>>>> +1 for moving to an extension that is not bundled by
default.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>> Could you elaborate a bit? You’re ok to break existing users?
What’s
>>>>> your
>>>>>>> rationale?
>>>>>>>
>>>>>>
>>>>>> AFAIK the Extension Manager doesn't delete pages without
asking you
>>> first
>>>>>> so you can choose to keep these pages (when asked). And if you
don't
>>> pay
>>>>>> attention when upgrading then you can restore them from the
recycle
> bin
>>>>> or
>>>>>> install the dedicated extension.
>>>>>
>>>>> Ok so you’re saying that users who upgrade will understand this and
>>>>> they’ll know what those technical pages do and thus they won’t let
EM
>>>>> delete them or they’ll understand that they need to install some
>>> dedicated
>>>>> extension?
>>>>>
>>>>
>>>> If they used these pages explicitly (e.g. adding the panel, including
> or
>>>> linking etc.) then they probably know what those pages do, so they can
>>>> decide whether to keep them or not.
>>>>
>>>> If they used these pages indirectly, because these pages were exposed
> in
>>>> the standard UI then:
>>>> * if they didn't modify the standard pages then the UI will be
updated
>>>> * if they modified the standard pages then they get a merge conflict,
>>> where
>>>> they can compare the previous version with the next version to see how
>>> the
>>>> "deprecated" pages have been replaced.
>>>
>>> I don’t think this is always true. For example imagine a user who
> created
>>> spaces with the Space Dashboard template. This created some home page in
>>> the space and those dashboard were using Main.Spaces (AFAIR).
>>>
>>> This is an example of a non-default page but the user doesn’t master its
>>> content.
>>>
>>> Thanks
>>> -Vincent
>>>
>>>>
>>>> Thanks,
>>>> Marius
>>>>
>>>>
>>>>>
>>>>> I was leaning to the safer legacy approach. The only downside I can
>>> think
>>>>> of about it is that you may keep some pages in your wiki that are
>>>>> deprecated/not needed.
>>>>>
>>>>> Thanks
>>>>> -Vincent
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Marius
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> -Vincent
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Marius
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, May 22, 2017 at 2:41 PM, Vincent Massol <
> vincent(a)massol.net
>>>>
>>>>>>>>> wrote:
>>>>>>>>>> Hi devs,
>>>>>>>>>>
>>>>>>>>>> We have this jira issue I created a while ago and
I’d like to
> move
>>>>>>>>> forward:
>>>>>>>>>>
https://jira.xwiki.org/browse/XWIKI-13101
>>>>>>>>>>
>>>>>>>>>> I have one question:
>>>>>>>>>> Should we move the 4 pages into a legacy module
in platform and
>>>>> bundle
>>>>>>>>> it in XE or just remove them?
>>>>>>>>>>
>>>>>>>>>> My POV:
>>>>>>>>>> We could consider the pages as APIs I guess and
use the API
>>> strategy
>>>>> of
>>>>>>>>> moving deprecated APIs to legacy.
>>>>>>>>>>
>>>>>>>>>> WDYT?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> -Vincent
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Thomas Mortagne