On Mon, May 22, 2017 at 4:44 PM, Vincent Massol <vinc...@massol.net> wrote:
>
>> On 22 May 2017, at 16:39, Thomas Mortagne <thomas.morta...@xwiki.com> wrote:
>>
>> On Mon, May 22, 2017 at 4:31 PM, Vincent Massol <vinc...@massol.net> wrote:
>>>
>>>> On 22 May 2017, at 16:27, Thomas Mortagne <thomas.morta...@xwiki.com>
>>>> wrote:
>>>>
>>>> On Mon, May 22, 2017 at 3:37 PM, Vincent Massol <vinc...@massol.net> wrote:
>>>>>
>>>>>> On 22 May 2017, at 15:34, Thomas Mortagne <thomas.morta...@xwiki.com>
>>>>>> wrote:
>>>>>>
>>>>>> I would be more in favor of moving them to some extension than can be
>>>>>> easily installed if really needed.
>>>>>
>>>>> The downside with this approach compared to the legacy approach are:
>>>>>
>>>>> * The user will gets broken before they can understand the problem and
>>>>> fix it so bad from a usability POV. They’ll also need to understand where
>>>>> to get the extension and install it
>>>>> * We break a contract if we consider that default pages are a contract
>>>>> (we need to decide about that but I think it would be fair to say the
>>>>> pages are a contract)
>>>>
>>>> Well by that definition we "broke" quite a lot of XE pages over the
>>>> years by moving them to not bundled contrib extensions or simply by
>>>> modifying some page that never been supposed to be API. Saying any
>>>> page is an API is really not a good idea in the current state. We
>>>> could discuss an explicit way to indicate what is an API and what is
>>>> internal for future pages if you want but right now It should be a
>>>> case by case I think.
>>>>
>>>> If you absolutely want to keep them, keep them. I'm just saying that I
>>>> would be OK to move them away (provided that they are easy to install
>>>> if really needed) since they display stuff that many recent users
>>>> won't understand ("space" ?) and I don't think they are used that much
>>>> in extensions.
>>>
>>> Yes but that’s not the main point. The main point is breaking the XWiki UI
>>> of the user who upgrades (and thus introducing a WTF effect - what I called
>>> a usability issue). So what you’re saying in essence, is that it’s ok to do
>>> so from your POV.
>>
>> I don't understand. Standard XE UI does not use those pages anywhere
>> anymore so what is going to be broken exactly when you upgrade ?
>> My
>> point is that it's only supposed to break extensions that would use
>> those pages or if the user have customization that rely on those pages
>> but that's true for any change in any page most of which never been
>> designed as APIs (so a lot less carefully than is required for an
>> API).
>
> Take for example the home page which was using Main.Spaces AFAIR. Imagine I’m
> on XWiki 7.x and I’ve customized the home page. When I upgrade to 9.x I’ll
> keep the home page that I’ve customized. So the home page will not get
> displayed correctly anymore (if it’s using an include, it’ll be missing
> content).
>
> I’d venture that 99% of wikis used for real have their home page customized
> and thus this should affect a lot of users.
I agree with the 99% but not so much with the fact that they keep the
spaces widget :)
>
> Thanks
> -Vincent
>
>>
>>>
>>> Any other opinion on this (I’d like more before deciding on something)?
>>>
>>> Thanks
>>> -Vincent
>>>
>>>>
>>>>>
>>>>> Thanks
>>>>> -Vincent
>>>>>
>>>>>> On Mon, May 22, 2017 at 2:41 PM, Vincent Massol <vinc...@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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thomas Mortagne
>>>
>>
>>
>>
>> --
>> Thomas Mortagne
>
--
Thomas Mortagne
