8 Apr
2016
8 Apr
'16
12:37 p.m.
Hi Alex,
On Fri, Apr 1, 2016 at 8:48 AM, Alexandru Cotiuga <
alexandru.cotiuga(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Thanks,
--
Denis Gervalle
SOFTEC sa - CEO