Hi Alex, On Fri, Apr 1, 2016 at 8:48 AM, Alexandru Cotiuga < [email protected]> wrote:
> Hello devs, > > Since I already experimented the Nested Spaces behaviour on the Forum > application and there are other applications that might need it also, I > think it's time to start discussing this topic and to decide what strategy > should be implemented on contrib applications. > 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. > What I have done in the Forum app was to handle both Pre NS and NS versions > of XWiki, writing specific code for each case (wrapped in if-else > statements), which proved to be the most complex and hard to maintain way, > without much benefit. Sooner or later, everybody will have a NS Xwiki > version and then all the support for Pre NS would become useless and then > the code should be cleaned, which would be a lot of work again. > 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. > Besides this already tried strategy, there are some others to be discused: > > 1: Support both Pre NS and NS versions but in different branches. > +0: The best, but probably requiring too much work in regards to our man power. > 2: Move to NS, but keep fixing bugs for Pre NS in a separate branch. (This > is what I'm proposing) > +1: definitely, the most reasonable solution for me during the next major release. > 3: Move to NS without any maintance on Pre NS. > +0: this could works unless a major bug is discovered on the application > 4: Others? > -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. > > In all the cases, a data migration should be performed. > > What we decide to do? > > Thanks, > Alex > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > Thanks, -- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
