FAQ
I think we need to put a stake in the ground for the 1.3 release...
more issues have been added, and in this mode we will never get there.

Some items *should* hold up a release:
- stability issues
- review of new APIs that will become finalized on release

We've had enough new features to warrant a new release for quite a
while, so I don't think any new big features should be going in unless
they are ready right now.

So how about we make a 1.4 branch in about 2 weeks (the 25th), and
release soon after.

-Yonik

Search Discussions

  • Chris Hostetter at Jul 10, 2008 at 4:41 pm
    : We've had enough new features to warrant a new release for quite a
    : while, so I don't think any new big features should be going in unless
    : they are ready right now.

    Looking at the pending issues, the only biggee seems to be SOLR-469,
    DataImportHandler ... my impression from the list is that it's ready, but
    that's really a question for Grant.

    if it takes a few more weeks to get DIH ready, I think holding the release
    is worth while -- there's a lot of interest in getting this into 1.3.

    SOLR-303 (Distributed Search) is also still open .. i'm not really
    clear from the comments what's left for that, but we should either resolve
    any remaining problems or roll it back to a state where it doesn't
    adversly affect existing users if it's not ready yet.

    Everything else on the list seems like they can easily fall into either
    the "trivial to commit" or "not a big deal to leave out" buckets depending
    on what kind of time people have -- but setting a cut-off date seems fine.



    -Hoss
  • Yonik Seeley at Jul 10, 2008 at 5:01 pm

    On Thu, Jul 10, 2008 at 12:40 PM, Chris Hostetter wrote:
    : We've had enough new features to warrant a new release for quite a
    : while, so I don't think any new big features should be going in unless
    : they are ready right now.

    Looking at the pending issues, the only biggee seems to be SOLR-469,
    DataImportHandler ... my impression from the list is that it's ready, but
    that's really a question for Grant.
    That's my impression too, but I've not been able to look at it myself.
    It's also going (mostly?) into contrib, right?
    SOLR-303 (Distributed Search) is also still open .. i'm not really
    clear from the comments what's left for that, but we should either resolve
    any remaining problems or roll it back to a state where it doesn't
    adversly affect existing users if it's not ready yet.
    I think it's ready to be closed. There are tons of limitations (i.e.
    much more devel to be done over time), but it's very useful as-is.

    -Yonik
  • Noble Paul നോബിള്‍ नोब्ळ् at Jul 10, 2008 at 5:57 pm
    The contrib patch is already committed. So DIH must be going into
    contrib. DIH will be an extra jar in the distro.

    If new features/fixes come up later the new jar can be dropped in and
    nothing else must break.
    If all the the external interfaces/(API & XML) are fine, any other
    changes that might come up later should be OK
    --Noble

    On Thu, Jul 10, 2008 at 10:30 PM, Yonik Seeley wrote:
    On Thu, Jul 10, 2008 at 12:40 PM, Chris Hostetter
    wrote:
    : We've had enough new features to warrant a new release for quite a
    : while, so I don't think any new big features should be going in unless
    : they are ready right now.

    Looking at the pending issues, the only biggee seems to be SOLR-469,
    DataImportHandler ... my impression from the list is that it's ready, but
    that's really a question for Grant.
    That's my impression too, but I've not been able to look at it myself.
    It's also going (mostly?) into contrib, right?
    SOLR-303 (Distributed Search) is also still open .. i'm not really
    clear from the comments what's left for that, but we should either resolve
    any remaining problems or roll it back to a state where it doesn't
    adversly affect existing users if it's not ready yet.
    I think it's ready to be closed. There are tons of limitations (i.e.
    much more devel to be done over time), but it's very useful as-is.

    -Yonik


    --
    --Noble Paul
  • Grant Ingersoll at Jul 11, 2008 at 9:50 pm

    On Jul 10, 2008, at 1:57 PM, Noble Paul നോബിള്‍ नोब्ळ् wrote:

    The contrib patch is already committed. So DIH must be going into
    contrib. DIH will be an extra jar in the distro.
    Yes, that is my plan.

    If new features/fixes come up later the new jar can be dropped in and
    nothing else must break.
    Yeah, I think we can put in DIH and mark it as experimental for this
    release, and not be so concerned about backwards compatibility. I
    have some use cases that I don't think fit with the current
    implementation, but haven't had time to work on them. Most of them
    have to do with dealing with lighter weight "on the fly"
    configurations. I think it is perfectly reasonable to want send in a
    select statement and have it executed. I also think there may be an
    issue with JDBC drivers being present when doing configuration, but
    that is minor. I'm also not sure on the connection handling code, but
    these are discussions for the issue, not this thread.

    If someone can go through and mark it as experimental on the patch (if
    it hasn't been done already) that would be good. Something to the
    effect that the DIH APIs are subject to change in the next release.
    Caveat Emptor.

    If all the the external interfaces/(API & XML) are fine, any other
    changes that might come up later should be OK
    We have had some discussion on the use of interfaces versus abstract
    classes. I need to revisit it and have a look again.

    -Grant
  • Noble Paul നോബിള്‍ नोब्ळ् at Jul 12, 2008 at 4:44 am
    How to make it mark as experimental? in Jira?
    On Sat, Jul 12, 2008 at 3:19 AM, Grant Ingersoll wrote:
    On Jul 10, 2008, at 1:57 PM, Noble Paul നോബിള്‍ नोब्ळ् wrote:

    The contrib patch is already committed. So DIH must be going into
    contrib. DIH will be an extra jar in the distro.
    Yes, that is my plan.

    If new features/fixes come up later the new jar can be dropped in and
    nothing else must break.
    Yeah, I think we can put in DIH and mark it as experimental for this
    release, and not be so concerned about backwards compatibility. I have some
    use cases that I don't think fit with the current implementation, but
    haven't had time to work on them. Most of them have to do with dealing with
    lighter weight "on the fly" configurations. I think it is perfectly
    reasonable to want send in a select statement and have it executed. I also
    think there may be an issue with JDBC drivers being present when doing
    configuration, but that is minor. I'm also not sure on the connection
    handling code, but these are discussions for the issue, not this thread.

    If someone can go through and mark it as experimental on the patch (if it
    hasn't been done already) that would be good. Something to the effect that
    the DIH APIs are subject to change in the next release. Caveat Emptor.

    If all the the external interfaces/(API & XML) are fine, any other
    changes that might come up later should be OK
    We have had some discussion on the use of interfaces versus abstract
    classes. I need to revisit it and have a look again.

    -Grant


    --
    --Noble Paul
  • Grant Ingersoll at Jul 12, 2008 at 12:03 pm
    I'd just put comments at the top of the classes in the javadocs, maybe
    just at the main entry points.

    -Grant

    On Jul 12, 2008, at 12:43 AM, Noble Paul നോബിള്‍
    नोब्ळ् wrote:
    How to make it mark as experimental? in Jira?

    On Sat, Jul 12, 2008 at 3:19 AM, Grant Ingersoll
    wrote:
    On Jul 10, 2008, at 1:57 PM, Noble Paul നോബിള്‍
    नोब्ळ् wrote:
    The contrib patch is already committed. So DIH must be going into
    contrib. DIH will be an extra jar in the distro.
    Yes, that is my plan.

    If new features/fixes come up later the new jar can be dropped in
    and
    nothing else must break.
    Yeah, I think we can put in DIH and mark it as experimental for this
    release, and not be so concerned about backwards compatibility. I
    have some
    use cases that I don't think fit with the current implementation, but
    haven't had time to work on them. Most of them have to do with
    dealing with
    lighter weight "on the fly" configurations. I think it is perfectly
    reasonable to want send in a select statement and have it
    executed. I also
    think there may be an issue with JDBC drivers being present when
    doing
    configuration, but that is minor. I'm also not sure on the
    connection
    handling code, but these are discussions for the issue, not this
    thread.

    If someone can go through and mark it as experimental on the patch
    (if it
    hasn't been done already) that would be good. Something to the
    effect that
    the DIH APIs are subject to change in the next release. Caveat
    Emptor.

    If all the the external interfaces/(API & XML) are fine, any other
    changes that might come up later should be OK
    We have had some discussion on the use of interfaces versus abstract
    classes. I need to revisit it and have a look again.

    -Grant


    --
    --Noble Paul
    --------------------------
    Grant Ingersoll
    http://www.lucidimagination.com

    Lucene Helpful Hints:
    http://wiki.apache.org/lucene-java/BasicsOfPerformance
    http://wiki.apache.org/lucene-java/LuceneFAQ
  • Lars Kotthoff at Jul 10, 2008 at 11:39 pm
    How about getting the user interface I wrote in with the release? I think it'd
    make a nice addition as something that's directly visible to the end-user.

    Lars
  • Erik Hatcher at Jul 11, 2008 at 10:00 am

    On Jul 10, 2008, at 7:37 PM, Lars Kotthoff wrote:
    How about getting the user interface I wrote in with the release? I
    think it'd
    make a nice addition as something that's directly visible to the end-
    user.
    I'd prefer not rushing that in, as it is a big contribution and needs
    a bit more review. (personally I think Spring MVC is overkill and
    less flexible, more verbose, than alternatives, but I'm strongly
    opinionated and will defer to others that desire this UI in Solr's
    codebase). I am quite impressed with the extensive manual that you
    wrote, and your example has gotten me looking into FreeMarker a bit
    deeper. Your hierarchical facet feature is interesting. And it made
    me smile to see the Ruby wikipedia loading code :) (look at solr-
    ruby's HpricotMapper, which may be useful to simplify it some)

    SOLR-620 is also the start of a built-in Solr UI framework, but I'm
    not going to rush that into 1.3.

    There is also Solr Flare, a Ruby on Rails Solr UI, which is already
    part of the Solr codebase that is a facet browsing, AJAX auto-
    suggesting interface. A great example of it is online here: <http://www.rondhuit-demo.com/yademo/
    . So folks aren't without at least a built-in alternative (albeit
    Ruby, so more involved to trying it out with the example app - though
    eventually this could be packaged as a .war using JRuby and dropped
    into the example webapps directory).

    Feedback: I noticed an error when just pressing the "Search" button on
    your demo without putting in a query. You'll probably want to default
    to a *:* query. And it'd also be cool to see facet values displayed
    _before_ doing a "search" so a user can browse without having to do a
    full-text search.

    Procedure-wise, most patches, including large ones like the
    DataImportHandler, are submitted via JIRA and assigned to the ASF,
    allowing folks one spot to download and comment on them. I consider
    that the first step to your push to get this in. Wiring your
    contribution in to the example area would ensure an easy way for folks
    to try it out.

    Erik
  • Lars Kotthoff at Jul 11, 2008 at 1:09 pm

    I'd prefer not rushing that in, as it is a big contribution and needs
    a bit more review. (personally I think Spring MVC is overkill and
    less flexible, more verbose, than alternatives, but I'm strongly
    opinionated and will defer to others that desire this UI in Solr's
    codebase).
    It probably is, but in terms of the code you have to write for the model and
    controller components, I think it's pretty good. I'm not a fan of heavyweight
    solutions myself, but as Solr itself needs to be deployed to a servlet
    container, using the same technologies for a UI seemed like a good choice.

    And in the end this will be but one of a large range of example Solr user
    interfaces.
    Feedback: I noticed an error when just pressing the "Search" button on
    your demo without putting in a query. You'll probably want to default
    to a *:* query. And it'd also be cool to see facet values displayed
    _before_ doing a "search" so a user can browse without having to do a
    full-text search.
    Ok, I hadn't considered that. The main purpose of the UI was to provide search
    functionality, and facets and everything else was designed more or less on top
    of that.

    I wouldn't want to make any changes now, but once this is part of Solr this can
    be added quite easily.
    Procedure-wise, most patches, including large ones like the
    DataImportHandler, are submitted via JIRA and assigned to the ASF,
    allowing folks one spot to download and comment on them. I consider
    that the first step to your push to get this in. Wiring your
    contribution in to the example area would ensure an easy way for folks
    to try it out.
    Ok. It'd be good if somebody could take a close look at it before though,
    because there're some jars which Solr uses as well, and dependencies on a Solr
    war for integration testing. Maybe the build script can be modified to not
    duplicate any jars in the repository and integrate the whole thing with the
    top-level build file.

    As for the timeframe, I'm obviously keen on getting it in as quickly as possible
    :), but I appreciate that you need to take a closer look at it. Let me know if
    there's anything I can help you with.

    Lars
  • Norberto Meijome at Jul 12, 2008 at 4:01 pm

    On Thu, 10 Jul 2008 11:56:00 -0400 "Yonik Seeley" wrote:

    I think we need to put a stake in the ground for the 1.3 release...
    more issues have been added, and in this mode we will never get there.

    Some items *should* hold up a release:
    - stability issues
    - review of new APIs that will become finalized on release

    We've had enough new features to warrant a new release for quite a
    while, so I don't think any new big features should be going in unless
    they are ready right now.
    hi,
    should the version of Jetty bundled with the sample app be updated from 6.1.3 to the latest 6.1.11? I just did it a bulk drop in and worked just fine .

    Although I included ALL the libraries included in Jetty's original binary distribution, it should be possible to keep it trimmed as it has been so far.

    I know it is hardly critical, but Jetty 6.1.3 seems to be about a year old.

    I'll be happy to test and provide instructions + files in Jira for someone to check in.

    Let me know what you think,
    B
    _________________________
    {Beto|Norberto|Numard} Meijome

    "Everything should be made as simple as possible, but not simpler."
    Albert Einstein

    I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned.
  • Yonik Seeley at Jul 12, 2008 at 4:26 pm
    I could go either way on a new Jetty upgrade:
    1) The current version has been tested for a year with this specific
    application (Solr) and thus it's less risky sticking with it, esp
    since we haven't seen any problems.
    2) Many bugs have been fixed in the latest patch release of Jetty...
    and just because we don't think we've encountered bugs in the old
    version doesn't mean that others won't.

    IMO, If we don't upgrade now, it makes sense to upgrade immediately
    after a 1.3 release.

    -Yonik
  • Norberto Meijome at Jul 12, 2008 at 4:42 pm

    On Sat, 12 Jul 2008 12:25:32 -0400 "Yonik Seeley" wrote:

    1) The current version has been tested for a year with this specific
    application (Solr) and thus it's less risky sticking with it, esp
    since we haven't seen any problems. agreed.
    2) Many bugs have been fixed in the latest patch release of Jetty...
    and just because we don't think we've encountered bugs in the old
    version doesn't mean that others won't.
    indeed, and these could affect newcomers to SOLR that use the sample setup as a
    comparison point... as I understand it, there have been some performance
    improvements in Jetty, at least on/from 6.1.5, but I don't know enough about it
    to say whether they would affect a SOLR installation.
    IMO, If we don't upgrade now, it makes sense to upgrade immediately
    after a 1.3 release.
    np - let me know how/when and I'll be happy to chip in.
    B
    _________________________
    {Beto|Norberto|Numard} Meijome

    My wish is that your day will be a good one.
    If not.......
    May the fleas of one thousand camels infest the crotch of the person who screws
    up your day and may their arms be too short to scratch.

    I speak for myself, not my employer. Contents may be hot. Slippery when wet.
    Reading disclaimers makes you go blind. Writing them is worse. You have been
    Warned.
  • Norberto Meijome at Jul 16, 2008 at 12:40 pm

    On Sun, 13 Jul 2008 02:00:24 +1000 Norberto Meijome wrote:

    On Thu, 10 Jul 2008 11:56:00 -0400
    "Yonik Seeley" wrote:
    I think we need to put a stake in the ground for the 1.3 release...
    more issues have been added, and in this mode we will never get there.

    Some items *should* hold up a release:
    - stability issues
    - review of new APIs that will become finalized on release

    We've had enough new features to warrant a new release for quite a
    while, so I don't think any new big features should be going in unless
    they are ready right now.
    hi,
    should the version of Jetty bundled with the sample app be updated from 6.1.3 to the latest 6.1.11? I just did it a bulk drop in and worked just fine .

    Although I included ALL the libraries included in Jetty's original binary distribution, it should be possible to keep it trimmed as it has been so far.

    I know it is hardly critical, but Jetty 6.1.3 seems to be about a year old.

    I'll be happy to test and provide instructions + files in Jira for someone to check in.

    Let me know what you think,
    Hi everyone,
    I've logged https://issues.apache.org/jira/browse/SOLR-632 with details on what needs to be changed. Maybe someone with commit bit can review & action , if deemed ok?

    thanks in advance,
    b

    _________________________
    {Beto|Norberto|Numard} Meijome

    "Tell a person you're the Metatron and they stare at you blankly. Mention something out of a Charleton Heston movie and suddenly everyone's a Theology scholar!"
    Dogma

    I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned.
  • Otis Gospodnetic at Jul 12, 2008 at 6:17 pm
    I'm pro 6.1.11. I've used it on several occasions now and haven't seen any problems with it.


    Otis
    --
    Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch


    ----- Original Message ----
    From: Norberto Meijome <freebsd@meijome.net>
    To: solr-dev@lucene.apache.org
    Sent: Saturday, July 12, 2008 6:40:44 PM
    Subject: Re: Solr 1.3 release date

    On Sat, 12 Jul 2008 12:25:32 -0400
    "Yonik Seeley" wrote:
    1) The current version has been tested for a year with this specific
    application (Solr) and thus it's less risky sticking with it, esp
    since we haven't seen any problems. agreed.
    2) Many bugs have been fixed in the latest patch release of Jetty...
    and just because we don't think we've encountered bugs in the old
    version doesn't mean that others won't.
    indeed, and these could affect newcomers to SOLR that use the sample setup as a
    comparison point... as I understand it, there have been some performance
    improvements in Jetty, at least on/from 6.1.5, but I don't know enough about it
    to say whether they would affect a SOLR installation.
    IMO, If we don't upgrade now, it makes sense to upgrade immediately
    after a 1.3 release.
    np - let me know how/when and I'll be happy to chip in.
    B
    _________________________
    {Beto|Norberto|Numard} Meijome

    My wish is that your day will be a good one.
    If not.......
    May the fleas of one thousand camels infest the crotch of the person who screws
    up your day and may their arms be too short to scratch.

    I speak for myself, not my employer. Contents may be hot. Slippery when wet.
    Reading disclaimers makes you go blind. Writing them is worse. You have been
    Warned.
  • Noble Paul നോബിള്‍ नोब्ळ् at Jul 12, 2008 at 6:43 pm
    we are dangerously close to a release.
    Do we have enough time to ensure that it won't throw any unpleasant surprises?

    On Sat, Jul 12, 2008 at 11:47 PM, Otis Gospodnetic
    wrote:
    I'm pro 6.1.11. I've used it on several occasions now and haven't seen any problems with it.


    Otis
    --
    Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch


    ----- Original Message ----
    From: Norberto Meijome <freebsd@meijome.net>
    To: solr-dev@lucene.apache.org
    Sent: Saturday, July 12, 2008 6:40:44 PM
    Subject: Re: Solr 1.3 release date

    On Sat, 12 Jul 2008 12:25:32 -0400
    "Yonik Seeley" wrote:
    1) The current version has been tested for a year with this specific
    application (Solr) and thus it's less risky sticking with it, esp
    since we haven't seen any problems. agreed.
    2) Many bugs have been fixed in the latest patch release of Jetty...
    and just because we don't think we've encountered bugs in the old
    version doesn't mean that others won't.
    indeed, and these could affect newcomers to SOLR that use the sample setup as a
    comparison point... as I understand it, there have been some performance
    improvements in Jetty, at least on/from 6.1.5, but I don't know enough about it
    to say whether they would affect a SOLR installation.
    IMO, If we don't upgrade now, it makes sense to upgrade immediately
    after a 1.3 release.
    np - let me know how/when and I'll be happy to chip in.
    B
    _________________________
    {Beto|Norberto|Numard} Meijome

    My wish is that your day will be a good one.
    If not.......
    May the fleas of one thousand camels infest the crotch of the person who screws
    up your day and may their arms be too short to scratch.

    I speak for myself, not my employer. Contents may be hot. Slippery when wet.
    Reading disclaimers makes you go blind. Writing them is worse. You have been
    Warned.


    --
    --Noble Paul
  • Ryan McKinley at Jul 12, 2008 at 6:51 pm
    I have been using 6.1.11 also.
    I think it should be safe to upgrade before 1.3

    On Jul 12, 2008, at 2:17 PM, Otis Gospodnetic wrote:
    I'm pro 6.1.11. I've used it on several occasions now and haven't
    seen any problems with it.


    Otis
    --
    Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch


    ----- Original Message ----
    From: Norberto Meijome <freebsd@meijome.net>
    To: solr-dev@lucene.apache.org
    Sent: Saturday, July 12, 2008 6:40:44 PM
    Subject: Re: Solr 1.3 release date

    On Sat, 12 Jul 2008 12:25:32 -0400
    "Yonik Seeley" wrote:
    1) The current version has been tested for a year with this specific
    application (Solr) and thus it's less risky sticking with it, esp
    since we haven't seen any problems. agreed.
    2) Many bugs have been fixed in the latest patch release of Jetty...
    and just because we don't think we've encountered bugs in the old
    version doesn't mean that others won't.
    indeed, and these could affect newcomers to SOLR that use the
    sample setup as a
    comparison point... as I understand it, there have been some
    performance
    improvements in Jetty, at least on/from 6.1.5, but I don't know
    enough about it
    to say whether they would affect a SOLR installation.
    IMO, If we don't upgrade now, it makes sense to upgrade immediately
    after a 1.3 release.
    np - let me know how/when and I'll be happy to chip in.
    B
    _________________________
    {Beto|Norberto|Numard} Meijome

    My wish is that your day will be a good one.
    If not.......
    May the fleas of one thousand camels infest the crotch of the
    person who screws
    up your day and may their arms be too short to scratch.

    I speak for myself, not my employer. Contents may be hot. Slippery
    when wet.
    Reading disclaimers makes you go blind. Writing them is worse. You
    have been
    Warned.
  • Yonik Seeley at Jul 28, 2008 at 12:54 pm

    On Thu, Jul 10, 2008 at 11:56 AM, Yonik Seeley wrote:
    So how about we make a 1.3 branch in about 2 weeks (the 25th), and
    release soon after.
    Given the flurry of recent activity, seems like extending this a
    little longer (another week?) would be a good idea.

    -Yonik
  • Noble Paul നോബിള്‍ नोब्ळ् at Jul 28, 2008 at 1:22 pm
    Let us do another round of bug scrubbing, Identify all the issues to
    be fixed in this release and defer some if it is not important for
    this release.
    On Mon, Jul 28, 2008 at 6:24 PM, Yonik Seeley wrote:
    On Thu, Jul 10, 2008 at 11:56 AM, Yonik Seeley wrote:
    So how about we make a 1.3 branch in about 2 weeks (the 25th), and
    release soon after.
    Given the flurry of recent activity, seems like extending this a
    little longer (another week?) would be a good idea.

    -Yonik


    --
    --Noble Paul
  • Shalin Shekhar Mangar at Jul 30, 2008 at 9:01 am
    We can't release with Lucene trunk jars, can we?
    On Mon, Jul 28, 2008 at 6:24 PM, Yonik Seeley wrote:
    On Thu, Jul 10, 2008 at 11:56 AM, Yonik Seeley wrote:
    So how about we make a 1.3 branch in about 2 weeks (the 25th), and
    release soon after.
    Given the flurry of recent activity, seems like extending this a
    little longer (another week?) would be a good idea.

    -Yonik


    --
    Regards,
    Shalin Shekhar Mangar.
  • Lars Kotthoff at Jul 30, 2008 at 9:10 am
    We can't release with Lucene trunk jars, can we?
    Ah, that reminds me of something. The feature added in SOLR-610 sort-of depends
    on LUCENE-1321 to work properly. This will only bite people who use SOLR-610 and
    try to highlight something at the very end of the field, so I don't think it's
    much of an issue.

    Nevertheless it's a reason to upgrade to the next release of Lucene as soon as
    it's available.

    Lars
  • Shalin Shekhar Mangar at Jul 30, 2008 at 9:15 am
    There are more. SpellCheckComponent and support for partial optimizes also
    depend on features in Lucene trunk.
    On Wed, Jul 30, 2008 at 2:40 PM, Lars Kotthoff wrote:

    We can't release with Lucene trunk jars, can we?
    Ah, that reminds me of something. The feature added in SOLR-610 sort-of
    depends
    on LUCENE-1321 to work properly. This will only bite people who use
    SOLR-610 and
    try to highlight something at the very end of the field, so I don't think
    it's
    much of an issue.

    Nevertheless it's a reason to upgrade to the next release of Lucene as soon
    as
    it's available.

    Lars


    --
    Regards,
    Shalin Shekhar Mangar.
  • Yonik Seeley at Jul 30, 2008 at 1:05 pm

    On Wed, Jul 30, 2008 at 5:01 AM, Shalin Shekhar Mangar wrote:
    We can't release with Lucene trunk jars, can we?
    We can if we feel comfortable with it.

    -Yonik

Related Discussions

People

Translate

site design / logo © 2019 Grokbase