On Wed, May 24, 2017 at 12:14 AM, Eduard Moraru <[email protected]> wrote: > On Tue, May 23, 2017 at 7:55 PM, Vincent Massol <[email protected]> wrote: > >> >> > On 23 May 2017, at 18:37, Eduard Moraru <[email protected]> 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 <[email protected]> >> wrote: >> > >> >> >> >>> On 23 May 2017, at 17:03, Marius Dumitru Florea < >> >> [email protected]> wrote: >> >>> >> >>> On Tue, May 23, 2017 at 5:07 PM, Vincent Massol <[email protected]> >> >> wrote: >> >>> >> >>>> >> >>>>> On 23 May 2017, at 16:01, Marius Dumitru Florea < >> >>>> [email protected]> wrote: >> >>>>> >> >>>>> On Tue, May 23, 2017 at 4:25 PM, Vincent Massol <[email protected]> >> >>>> wrote: >> >>>>> >> >>>>>> >> >>>>>>> On 23 May 2017, at 15:22, Marius Dumitru Florea < >> >>>>>> [email protected]> wrote: >> >>>>>>> >> >>>>>>> On Mon, May 22, 2017 at 4:34 PM, Thomas Mortagne < >> >>>>>> [email protected]> >> >>>>>>> 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 < >> [email protected] >> >>> >> >>>>>>>> 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
