The proposal is not about breaking the lucene plugin but to give it it's own (not very exciting) life as an extension that is not very hard to install. If someone still needs it, installing it is pretty easy. Since we don't plan to support it there is no real value in keeping it in platform.
I actually prefer a lot moving the remaining bugs in a new jira project that would be created for this new contrib project than closing everything as won't fix. On Thu, Sep 12, 2013 at 5:51 PM, Sergiu Dumitriu <[email protected]> wrote: > On 09/12/2013 11:37 AM, Vincent Massol wrote: >> >> On Sep 12, 2013, at 5:21 PM, Sergiu Dumitriu <[email protected]> wrote: >> >>> On 09/12/2013 10:48 AM, Vincent Massol wrote: >>>> Hi devs, >>>> >>>> Now that we have a SOLR search, I think we should close all Lucene-related >>>> JIRA issues as won't fix, remove the Lucene search by default in XWiki 5.3 >>>> and move it to xwiki-contrib. >>>> >>>> I don't think we want to maintain 2 implementation especially since the >>>> SOLR one is better. >>>> >>>> Here's my +1. >>>> >>> >>> -1. Although it's just a plugin, the Lucene search has been available >>> for a very long time, so I view it as an API. And a rather important one. >> >> The API won't change. Quite the opposite the proposal is about freezing it :) >> >>> The search has been often customized on client projects, so it's not >>> just the default wiki search that's using the Lucene index and the >>> Lucene search API. Is there a migration plan for porting those custom >>> searches to the new Solr search? Are we sure the Solr index has support >>> for all the features that the Lucene one had? >>> >>> We should follow the standard deprecation strategy: >>> >>> - mark the plugin as deprecated >>> - warn users that they should switch to Solr >>> - write a migration guide >>> - after a few releases (6.1?), remove the search UI (we still have the >>> even older DatabaseSearch UI available, why not keep the Lucene one a >>> bit longer?) >>> - after a few more releases (7.1?), retire the plugin >> >> The Lucene modules will still be available, just not bundled by default. You >> could install them with the EM if you need them. >> >> Whoever is already using Lucene will have the extensions installed and >> upgrading will not remove them AFAIK. > > Yes it will. Upgrading usually means remove the old webapp libs > (including the Lucene one) and add the new libs (now without Lucene). We > don't have a full upgrade tool that would nicely merge the webapps. Even > if we did, how would it know which jars to keep and which to remove, > since every XWiki jar can be potentially upgraded, removed for good > reasons, removed because it's deprecated, or have its name changed. > >> We're not that many in term of devs and even you have much less time to work >> on XWiki lately. We need to move on. I feel this proposal doesn't break >> anything important for users/developers. > > Yet we have a lot of old code that's not getting removed. If it won't > change, why not follow our deprecation policies? Are rules supposed to > be followed only if we feel like it? It's not like it costs us anything > to keep it in the sources and not touch it, the release process > automatically builds it for us. > >> The net effect of this proposal is about freezing any dev on Lucene and not >> releasing it anymore. It should continue to work as now on older versions. >> >> Thanks >> -Vincent >> >>> But yes, we could close Lucene-related issues that we're not going to fix. > > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
