13 Sep
2013
13 Sep
'13
3:21 p.m.
On 09/13/2013 08:51 AM, Thomas Mortagne wrote:
On Thu, Sep 12, 2013 at 5:11 PM, Sergiu Dumitriu
<sergiu(a)xwiki.com> wrote:
Given that as a downstream user I don't really use multiwikis in any
way, this doesn't affect me at all. So +1, less code is always better.
One product less means less confusion for users.
My main complaint was about the backwards compatibility rule that's not
being followed.
--
Sergiu Dumitriu
http://purl.org/net/sergiu
On 09/11/2013 05:58 AM, Guillaume
"Louis-Marie" Delhumeau wrote:
XEM became a workspaces manager in 3.3 (see
http://jira.xwiki.org/browse/XEM-202) so there is nothing new here.
The only difference between the new XE and XEM is that wiki manager UI
is not included while it was hidden in XEM so it's not a big change
for users since it's super easy to install with Extension Manager.
XEM is and always been pretty much only a set of pom.xml files with
dependencies and not much more than a home page. Guillaume moved
Workspaces from XEM to XE making XEM pretty much useless now.
Since Enterprise embeds Workspaces by default
since 5.2-m2, I think it does
not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager:
- stop releasing it
- move the github repo to xwiki-contrib/retired
- update manager.xwiki.org to explain the changes in XWiki 5.2.
- move the manager jira to the retired category
- remove the build in ci.xwiki.org
Here is my non-binding +1.
LM
-1. This is very premature, the new workspaces haven't been available
for a long enough time to be sure it is a good replacement for XEM.
Do workspaces fulfill all the needs of existing XEM users?
Does the new implementation offer support for the Farm usage?
You can install Wiki Manager UI using Extension Manager.
Is there a clear migration path? Manual or automatic?
Is the new wiki management UI going to be at least as easy to use as the
old one? What's the learning curve for administrators?
If the build is broken, it's easier to fix it than to upset a large
userbase. Why do we insist so much on maintaining backwards
compatibility for Java APIs that we're almost certain nobody uses, yet
we're OK with dropping an entire product without a proven alternative,
hoping that in one or two more releases that alternative will actually
be fully implemented?
The point here is that the alternative is XE. We don't remove XEM
because the build is broken... It simply does not worth the effort to
keep it anymore since XE expose the same features.