+1
Thanks,
Eduard
On Thu, Sep 19, 2013 at 4:35 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
Almost everybody has voted so I think this
proposal is approved.
2013/9/13 Sergiu Dumitriu <sergiu(a)xwiki.com>
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:
>> On 09/11/2013 05:58 AM, Guillaume "Louis-Marie" Delhumeau wrote:
>>> 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?
>
> 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.
>
>>
>> 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.
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org