Hello all, I think the best would be 2, but it could be discussed on an app by app basis and, in my opinion, the options need to be looked in the context of what does it mean that an "application needs to pass to Nested Spaces". This is my view on it: - Requirement of a nested spaces version should be done if the functionalities of the application demand it (there is a feature that is added to the functionality that needs nested spaces in order to work) - Note that application can *work* on nested spaces without *requiring* nested spaces (because of the general backwards compatibility of nested spaces feature), this bullet above is about requiring nested spaces. - Even if previous versions can still be supported by an application migrated to nested spaces, if this adds a lot of bloat and "if"s in the code and extra complexity, the benefits are probably not worth it (it should still be discussed though) - this would be option 0 - A particular case is when an application does not work on nested spaces in its current form and needs to be modified to support nested spaces. In this case, there needs to be an effort to find a reasonable approach that would allow the application to work, with the same code, on both nested spaces and non-nested spaces (which could be possible because of the generic backwards compat of nested spaces) Otherwise put, I am fine that there are applications on which we apply 2 (and even 3) , but there needs to be a good reason to pass to Nested Spaces for an application, potentially joined by a validation discussion with the community. If we decide we go to nested for an app, both 2 and 3 are fine. In such a case I would be against option 0 that Vincent mentioned: adds complexity and bloats the code for an application, raises the learning curve and it will be removed in the future. Now please note that applying 2 means that if you're in the middle of the developpement for a version of an application, on which some issues were already fixed, and you want to move to a nested spaces version, it would be nice to release current work first as the "last version before nested spaces" and only then break compat. This is also valid for planning the versions of the application: bugfixes / features that don't require nested spaces should be planned in earlier, separate versions than features that would require nested spaces. On Fri, Apr 1, 2016 at 8:48 AM, Alexandru Cotiuga < alexandru.cotiuga(a)xwiki.com&gt; wrote: Depends on what we understand by data migration: if the data format changes (e.g. the data of the application needs to have a new hierarchical structure because a functionality requires this hierarchy - e.g. inheriting rights) then we need to have a data migration, as in take into account the fact that there will be upgrades of the application, and that we should have an unique format of data for the application in question (e.g. there is no reason that the data structure is different between a user that has installed the app on a fresh 7.4 and a user that has upgraded the application from a previous version on a 7.4 xwiki). If "data migration" is about just transforming all existing pages of an/created by an application (which are terminal) into non-terminal pages, then it should not be done unless there is a feature that requires it. I think this data migration needs to be looked at as a change in the application data structure (from a 2 levels hierarchy to an infinite hierarchy) and should be done only if there is a functional benefit that justifies it. In this context, breaking compat of the FAQ app by moving the FAQ pages to a "Data" subspace of the FAQ space for the sole reason that this is what AWM is doing now is not ok, because the reason is not good enough. So, imo, since these reasons will really differ from app to app and evaluation of what "good reason" means depends on the evaluator, we should try to reach consensus by discussing it on a case by case basis, and not have a single rule applied blindly. I think I repeated myself 3 times, sorry you had to read through all of it :D Have fun, Anca

Hi Alex, On Fri, Apr 1, 2016 at 8:48 AM, Alexandru Cotiuga < alexandru.cotiuga(a)xwiki.com&gt; wrote: This is indeed an important discussion, I would have even prefer that we had it before the recent change you made into the Forum app. First of all, as Anca and Marius precise, we need to know what we mean by an NS version of the application. And like them, I consider that we should only move an application to NS when it brings some value to the application itself, but not only IMO, also when it could pave the road for further improvement or improve the integration with the wiki. IMO, the key here, is that it should not be just a code style operation ! For those applications, that will really change their storage model to nested spaces, you will find my thought to your questions below. Not only that, there is also a very high risk that further change in the application be only tested under NS, and that we believe it works on non-NS, while it is no more the case. Maintaining an application that should work with data using very different models is very dangerous, and cost a lot if you want to ensure proper testing. There is also a lot of weird cases when you migrate from one storage to another if you do not proceed to a migration of the data. So, yes, if the data model change, the migration is required, and supporting both models in the same application seems to be very hard with no real benefit, and a lot of risks. +0: The best, but probably requiring too much work in regards to our man power. +1: definitely, the most reasonable solution for me during the next major release. +0: this could works unless a major bug is discovered on the application -1: for mixing two data model in the same code base -0: for mixing support unless the improvement are trivial enough that my fear described above could not arise. Thanks, -- Denis Gervalle SOFTEC sa - CEO