22 May
2017
22 May
'17
4:51 p.m.
On Mon, May 22, 2017 at 4:46 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
--
Thomas Mortagne
On Mon, May 22, 2017 at 4:44 PM, Vincent Massol
<vincent(a)massol.net> wrote:
I agree with the 99% but not so much with the fact that they keep the
spaces widget :)
Note: we replaced the space panel in the dashboard by a pages panel in 7.2.
On 22 May 2017, at 16:39, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Mon, May 22, 2017 at 4:31 PM, Vincent Massol <vincent(a)massol.net> wrote:
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.
> On 22 May 2017, at 16:27, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote:
>
> On Mon, May 22, 2017 at 3:37 PM, Vincent Massol <vincent(a)massol.net> wrote:
>>
>>> On 22 May 2017, at 15:34, 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.
>>
>> 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).
Thanks
-Vincent
--
Thomas Mortagne
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 <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
>>
>
>
>
> --
> Thomas Mortagne
--
Thomas Mortagne