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.coti...@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.
>
> 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.
>
> Besides this already tried strategy, there are some others to be discused:
>
> 1: Support both Pre NS and NS versions but in different branches.
> 2: Move to NS, but keep fixing bugs for Pre NS in a separate branch. (This
> is what I'm proposing)
> 3: Move to NS without any maintance on Pre NS.
> 4: Others?
>
> In all the cases, a data migration should be performed.
>
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
>
> What we decide to do?
>
> Thanks,
> Alex
> _______________________________________________
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
