[xwiki-devs] [Proposal] Removed deprecated "Panels.SpaceDocs", "Panels.Spaces", "Main.Spaces" and "Main.SpaceIndex"
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
I would be more in favor of moving them to some extension than can be easily installed if really needed. On Mon, May 22, 2017 at 2:41 PM, Vincent Massol <vincent@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
On 22 May 2017, at 15:34, Thomas Mortagne <thomas.mortagne@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) Thanks -Vincent
On Mon, May 22, 2017 at 2:41 PM, Vincent Massol <vincent@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
On Mon, May 22, 2017 at 3:37 PM, Vincent Massol <vincent@massol.net> wrote:
On 22 May 2017, at 15:34, Thomas Mortagne <thomas.mortagne@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.
Thanks -Vincent
On Mon, May 22, 2017 at 2:41 PM, Vincent Massol <vincent@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
On 22 May 2017, at 16:27, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, May 22, 2017 at 3:37 PM, Vincent Massol <vincent@massol.net> wrote:
On 22 May 2017, at 15:34, Thomas Mortagne <thomas.mortagne@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. 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@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
On Mon, May 22, 2017 at 4:31 PM, Vincent Massol <vincent@massol.net> wrote:
On 22 May 2017, at 16:27, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, May 22, 2017 at 3:37 PM, Vincent Massol <vincent@massol.net> wrote:
On 22 May 2017, at 15:34, Thomas Mortagne <thomas.mortagne@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).
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@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
On 22 May 2017, at 16:39, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, May 22, 2017 at 4:31 PM, Vincent Massol <vincent@massol.net> wrote:
On 22 May 2017, at 16:27, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, May 22, 2017 at 3:37 PM, Vincent Massol <vincent@massol.net> wrote:
On 22 May 2017, at 15:34, Thomas Mortagne <thomas.mortagne@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. 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 <vincent@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
On Mon, May 22, 2017 at 4:44 PM, Vincent Massol <vincent@massol.net> wrote:
On 22 May 2017, at 16:39, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, May 22, 2017 at 4:31 PM, Vincent Massol <vincent@massol.net> wrote:
On 22 May 2017, at 16:27, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, May 22, 2017 at 3:37 PM, Vincent Massol <vincent@massol.net> wrote:
On 22 May 2017, at 15:34, Thomas Mortagne <thomas.mortagne@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 <vincent@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
On Mon, May 22, 2017 at 4:46 PM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, May 22, 2017 at 4:44 PM, Vincent Massol <vincent@massol.net> wrote:
On 22 May 2017, at 16:39, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, May 22, 2017 at 4:31 PM, Vincent Massol <vincent@massol.net> wrote:
On 22 May 2017, at 16:27, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, May 22, 2017 at 3:37 PM, Vincent Massol <vincent@massol.net> wrote:
> On 22 May 2017, at 15:34, Thomas Mortagne <thomas.mortagne@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 :)
Note: we replaced the space panel in the dashboard by a pages panel in 7.2.
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 <vincent@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
-- Thomas Mortagne
On 22 May 2017, at 16:46, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, May 22, 2017 at 4:44 PM, Vincent Massol <vincent@massol.net> wrote:
On 22 May 2017, at 16:39, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, May 22, 2017 at 4:31 PM, Vincent Massol <vincent@massol.net> wrote:
On 22 May 2017, at 16:27, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, May 22, 2017 at 3:37 PM, Vincent Massol <vincent@massol.net> wrote:
> On 22 May 2017, at 15:34, Thomas Mortagne <thomas.mortagne@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 :)
Indeed :) There’s another use case in addition to the 2 you mentioned above: if the user has created pages or panels using those pages (for example space dashboards). Thanks -Vincent
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 <vincent@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
On Mon, May 22, 2017 at 4:34 PM, Thomas Mortagne <thomas.mortagne@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. Thanks, Marius
On Mon, May 22, 2017 at 2:41 PM, Vincent Massol <vincent@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
On 23 May 2017, at 15:22, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote:
On Mon, May 22, 2017 at 4:34 PM, Thomas Mortagne <thomas.mortagne@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? Thanks -Vincent
Thanks, Marius
On Mon, May 22, 2017 at 2:41 PM, Vincent Massol <vincent@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
On Tue, May 23, 2017 at 4:25 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 15:22, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Mon, May 22, 2017 at 4:34 PM, Thomas Mortagne < thomas.mortagne@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. Thanks, Marius
Thanks -Vincent
Thanks, Marius
On Mon, May 22, 2017 at 2:41 PM, Vincent Massol <vincent@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
On 23 May 2017, at 16:01, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote:
On Tue, May 23, 2017 at 4:25 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 15:22, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Mon, May 22, 2017 at 4:34 PM, Thomas Mortagne < thomas.mortagne@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? 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@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
On Tue, May 23, 2017 at 5:07 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 16:01, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Tue, May 23, 2017 at 4:25 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 15:22, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Mon, May 22, 2017 at 4:34 PM, Thomas Mortagne < thomas.mortagne@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. 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@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
On 23 May 2017, at 17:03, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote:
On Tue, May 23, 2017 at 5:07 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 16:01, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Tue, May 23, 2017 at 4:25 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 15:22, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Mon, May 22, 2017 at 4:34 PM, Thomas Mortagne < thomas.mortagne@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@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
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. 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. So I`m +1 for removing them. Thanks, Eduard On Tue, May 23, 2017 at 6:33 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 17:03, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Tue, May 23, 2017 at 5:07 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 16:01, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Tue, May 23, 2017 at 4:25 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 15:22, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Mon, May 22, 2017 at 4:34 PM, Thomas Mortagne < thomas.mortagne@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@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
On 23 May 2017, at 18:37, Eduard Moraru <enygma2002@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).
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@massol.net> wrote:
On 23 May 2017, at 17:03, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Tue, May 23, 2017 at 5:07 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 16:01, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Tue, May 23, 2017 at 4:25 PM, Vincent Massol <vincent@massol.net> wrote:
> On 23 May 2017, at 15:22, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote: > > On Mon, May 22, 2017 at 4:34 PM, Thomas Mortagne < thomas.mortagne@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@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
On Tue, May 23, 2017 at 6:55 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 18:37, Eduard Moraru <enygma2002@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).
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?
"hard work" is a bit strong :)
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@massol.net> wrote:
On 23 May 2017, at 17:03, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Tue, May 23, 2017 at 5:07 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 16:01, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Tue, May 23, 2017 at 4:25 PM, Vincent Massol <vincent@massol.net> wrote:
> >> On 23 May 2017, at 15:22, Marius Dumitru Florea < > mariusdumitru.florea@xwiki.com> wrote: >> >> On Mon, May 22, 2017 at 4:34 PM, Thomas Mortagne < > thomas.mortagne@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@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
On 23 May 2017, at 18:58, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Tue, May 23, 2017 at 6:55 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 18:37, Eduard Moraru <enygma2002@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).
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?
"hard work" is a bit strong :)
Removing takes a few seconds. Doing the moves means: * Create git repo * Document the git repo (README.md file) * Create jira project * Create JIRA issues and close * Create Maven structure * Copy git content (possibly saving the history too) * Test manually * Release in Maven + JIRA * Import & Document on e.x.o That’s several hours. Thanks -Vincent
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@massol.net> wrote:
On 23 May 2017, at 17:03, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Tue, May 23, 2017 at 5:07 PM, Vincent Massol <vincent@massol.net> wrote:
> On 23 May 2017, at 16:01, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote: > > On Tue, May 23, 2017 at 4:25 PM, Vincent Massol <vincent@massol.net> wrote: > >> >>> On 23 May 2017, at 15:22, Marius Dumitru Florea < >> mariusdumitru.florea@xwiki.com> wrote: >>> >>> On Mon, May 22, 2017 at 4:34 PM, Thomas Mortagne < >> thomas.mortagne@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@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
On Tue, May 23, 2017 at 7:10 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 18:58, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Tue, May 23, 2017 at 6:55 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 18:37, Eduard Moraru <enygma2002@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).
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?
"hard work" is a bit strong :)
Removing takes a few seconds.
Doing the moves means: * Create git repo * Document the git repo (README.md file)
* Create jira project * Create JIRA issues and close
Why on earth would we create a Jira project for something nobody is going to modify, ever.
* Create Maven structure * Copy git content (possibly saving the history too) * Test manually
Not sure what more than installing the extension you want to test.
* Release in Maven + JIRA * Import & Document on e.x.o
That’s several hours.
Jira project is totally useless here and "several hours" is not very realistic for publishing a 4 pages XAR extension IMO.
Thanks -Vincent
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@massol.net> wrote:
On 23 May 2017, at 17:03, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Tue, May 23, 2017 at 5:07 PM, Vincent Massol <vincent@massol.net> wrote:
> >> On 23 May 2017, at 16:01, Marius Dumitru Florea < > mariusdumitru.florea@xwiki.com> wrote: >> >> On Tue, May 23, 2017 at 4:25 PM, Vincent Massol <vincent@massol.net> > wrote: >> >>> >>>> On 23 May 2017, at 15:22, Marius Dumitru Florea < >>> mariusdumitru.florea@xwiki.com> wrote: >>>> >>>> On Mon, May 22, 2017 at 4:34 PM, Thomas Mortagne < >>> thomas.mortagne@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@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
On Tue, May 23, 2017 at 7:55 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 18:37, Eduard Moraru <enygma2002@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. 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? 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. 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@massol.net>
wrote:
On 23 May 2017, at 17:03, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Tue, May 23, 2017 at 5:07 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 16:01, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Tue, May 23, 2017 at 4:25 PM, Vincent Massol <vincent@massol.net> wrote:
> >> On 23 May 2017, at 15:22, Marius Dumitru Florea < > mariusdumitru.florea@xwiki.com> wrote: >> >> On Mon, May 22, 2017 at 4:34 PM, Thomas Mortagne < > thomas.mortagne@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@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
On Wed, May 24, 2017 at 12:14 AM, Eduard Moraru <enygma2002@gmail.com> wrote:
On Tue, May 23, 2017 at 7:55 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 18:37, Eduard Moraru <enygma2002@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. 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?
Note: no we are not doing this with deprecated Java APIs actually. You are mixing with @Unstable rule I think. The current rule is to never fully "dropping/removing/killing them with fire", just when it's not too hard extract them in easily installable extensions after a while (which is what I'm proposing here, 7.2 -> 9.4 sounds like "a while" enough to me).
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.
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@massol.net>
wrote:
On 23 May 2017, at 17:03, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Tue, May 23, 2017 at 5:07 PM, Vincent Massol <vincent@massol.net> wrote:
> On 23 May 2017, at 16:01, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote: > > On Tue, May 23, 2017 at 4:25 PM, Vincent Massol <vincent@massol.net> wrote: > >> >>> On 23 May 2017, at 15:22, Marius Dumitru Florea < >> mariusdumitru.florea@xwiki.com> wrote: >>> >>> On Mon, May 22, 2017 at 4:34 PM, Thomas Mortagne < >> thomas.mortagne@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@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
Hi Edy and all,
On 24 May 2017, at 00:14, Eduard Moraru <enygma2002@gmail.com> wrote:
On Tue, May 23, 2017 at 7:55 PM, Vincent Massol <vincent@massol.net> wrote:
On 23 May 2017, at 18:37, Eduard Moraru <enygma2002@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@massol.net>
wrote:
On 23 May 2017, at 17:03, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
On Tue, May 23, 2017 at 5:07 PM, Vincent Massol <vincent@massol.net> wrote:
> On 23 May 2017, at 16:01, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote: > > On Tue, May 23, 2017 at 4:25 PM, Vincent Massol <vincent@massol.net> wrote: > >> >>> On 23 May 2017, at 15:22, Marius Dumitru Florea < >> mariusdumitru.florea@xwiki.com> wrote: >>> >>> On Mon, May 22, 2017 at 4:34 PM, Thomas Mortagne < >> thomas.mortagne@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@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
participants (4)
-
Eduard Moraru -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol