FAQ
What should the next version of Solr be?

Options:
- have a Solr 1.5 with a lucene 2.9.x
- have a Solr 1.5 with a lucene 3.x, with weaker back compat given all
of the removed lucene deprecations from 2.9->3.0
- have a Solr 2.0 with a lucene 3.x

-Yonik
http://www.lucidimagination.com

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org

Search Discussions

  • Simon Willnauer at Nov 19, 2009 at 8:46 am

    On Thu, Nov 19, 2009 at 2:53 AM, Yonik Seeley wrote:
    What should the next version of Solr be?

    Options:
    - have a Solr 1.5 with a lucene 2.9.x
    - have a Solr 1.5 with a lucene 3.x, with weaker back compat given all
    of the removed lucene deprecations from 2.9->3.0
    - have a Solr 2.0 with a lucene 3.x
    My first feeling is that Solr 2.0 with Lucene 3.x would be a clean
    cut. What is your back compat policy for major version jumps?
    -Yonik
    http://www.lucidimagination.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org
  • Uwe Schindler at Nov 19, 2009 at 8:58 am
    It depends on how much work it is to remove the rest of the not per-segment
    able stuff in Solr. If this can be done shortly, I would choose option 2 or
    3 with no preference, as I do not know your backwards compatibility
    requirements.

    By the way, you wanted to send us your last Solr TokenStreams still using
    the old API?

    Uwe

    -----
    Uwe Schindler
    H.-H.-Meier-Allee 63, D-28213 Bremen
    http://www.thetaphi.de
    eMail: uwe@thetaphi.de

    -----Original Message-----
    From: yseeley@gmail.com On Behalf Of Yonik
    Seeley
    Sent: Thursday, November 19, 2009 2:53 AM
    To: java-dev@lucene.apache.org
    Subject: Solr 1.5 or 2.0?

    What should the next version of Solr be?

    Options:
    - have a Solr 1.5 with a lucene 2.9.x
    - have a Solr 1.5 with a lucene 3.x, with weaker back compat given all
    of the removed lucene deprecations from 2.9->3.0
    - have a Solr 2.0 with a lucene 3.x

    -Yonik
    http://www.lucidimagination.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org
  • Yonik Seeley at Nov 19, 2009 at 2:31 pm
    Oops... of course I meant to post this in solr-dev.

    -Yonik
    http://www.lucidimagination.com

    On Wed, Nov 18, 2009 at 8:53 PM, Yonik Seeley
    wrote:
    What should the next version of Solr be?

    Options:
    - have a Solr 1.5 with a lucene 2.9.x
    - have a Solr 1.5 with a lucene 3.x, with weaker back compat given all
    of the removed lucene deprecations from 2.9->3.0
    - have a Solr 2.0 with a lucene 3.x

    -Yonik
    http://www.lucidimagination.com
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org
  • Uwe Schindler at Nov 19, 2009 at 2:40 pm
    We also had some (maybe helpful) opinions :-)

    -----
    Uwe Schindler
    H.-H.-Meier-Allee 63, D-28213 Bremen
    http://www.thetaphi.de
    eMail: uwe@thetaphi.de

    -----Original Message-----
    From: yseeley@gmail.com On Behalf Of Yonik
    Seeley
    Sent: Thursday, November 19, 2009 3:31 PM
    To: java-dev@lucene.apache.org
    Subject: Re: Solr 1.5 or 2.0?

    Oops... of course I meant to post this in solr-dev.

    -Yonik
    http://www.lucidimagination.com

    On Wed, Nov 18, 2009 at 8:53 PM, Yonik Seeley
    wrote:
    What should the next version of Solr be?

    Options:
    - have a Solr 1.5 with a lucene 2.9.x
    - have a Solr 1.5 with a lucene 3.x, with weaker back compat given all
    of the removed lucene deprecations from 2.9->3.0
    - have a Solr 2.0 with a lucene 3.x

    -Yonik
    http://www.lucidimagination.com
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org
  • Noble Paul നോബിള്‍ नोब्ळ् at Nov 19, 2009 at 2:52 pm
    option 3 looks best . But do we plan to remove anything we have not
    already marked as deprecated?
    On Thu, Nov 19, 2009 at 8:10 PM, Uwe Schindler wrote:
    We also had some (maybe helpful) opinions :-)

    -----
    Uwe Schindler
    H.-H.-Meier-Allee 63, D-28213 Bremen
    http://www.thetaphi.de
    eMail: uwe@thetaphi.de

    -----Original Message-----
    From: yseeley@gmail.com On Behalf Of Yonik
    Seeley
    Sent: Thursday, November 19, 2009 3:31 PM
    To: java-dev@lucene.apache.org
    Subject: Re: Solr 1.5 or 2.0?

    Oops... of course I meant to post this in solr-dev.

    -Yonik
    http://www.lucidimagination.com

    On Wed, Nov 18, 2009 at 8:53 PM, Yonik Seeley
    wrote:
    What should the next version of Solr be?

    Options:
    - have a Solr 1.5 with a lucene 2.9.x
    - have a Solr 1.5 with a lucene 3.x, with weaker back compat given all
    of the removed lucene deprecations from 2.9->3.0
    - have a Solr 2.0 with a lucene 3.x

    -Yonik
    http://www.lucidimagination.com
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org


    --
    -----------------------------------------------------
    Noble Paul | Principal Engineer| AOL | http://aol.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org
  • Ryan McKinley at Nov 19, 2009 at 11:16 pm
    I would love to set goals that are ~3 months out so that we don't have
    another 1 year release cycle. For a 2.0 release where we could have
    more back-compatibly flexibility, i would love to see some work that
    may be too ambitious... In particular, the config spaghetti needs
    some attention.

    I don't see the need to increment solr to 2.0 for the lucene 3.0
    change -- of course that needs to be noted, but incrementing the major
    number in solr only makes sense if we are going to change *solr*
    significantly.

    The lucene 2.x -> 3.0 upgrade path seems independent of that to me. I
    would even argue that with solr 1.4 we have already required many
    lucene 3.0 changes -- All my custom lucene stuff had to be reworked to
    work with solr 1.4 (tokenizers & multi-reader filters).

    In general, I wonder where the solr back-compatibility contract
    applies (and to what degree). For solr, I would rank the importance as:
    #1 - the URL API syntax. Client query parameters should change as
    little as possible
    #2 - configuration
    #3 - java APIs

    With that in mind, i think 'solr 1.5 with lucene 3.x' makes the most
    sense. Unless we see making serious changes to solr that would
    warrent a major release bump.

    Lucene has an explict back-compatibility contract:
    http://wiki.apache.org/lucene-java/BackwardsCompatibility

    I don't know if solr has one... if we make one, I would like it to
    focus on the URL syntax+configuration

    ryan


    On Nov 18, 2009, at 5:53 PM, Yonik Seeley wrote:

    What should the next version of Solr be?

    Options:
    - have a Solr 1.5 with a lucene 2.9.x
    - have a Solr 1.5 with a lucene 3.x, with weaker back compat given all
    of the removed lucene deprecations from 2.9->3.0
    - have a Solr 2.0 with a lucene 3.x

    -Yonik
    http://www.lucidimagination.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org
  • Mark Miller at Nov 19, 2009 at 11:35 pm

    Ryan McKinley wrote:
    I would love to set goals that are ~3 months out so that we don't have
    another 1 year release cycle. For a 2.0 release where we could have
    more back-compatibly flexibility, i would love to see some work that
    may be too ambitious... In particular, the config spaghetti needs
    some attention.

    I don't see the need to increment solr to 2.0 for the lucene 3.0
    change -- of course that needs to be noted, but incrementing the major
    number in solr only makes sense if we are going to change *solr*
    significantly.
    Lucene major numbers don't work that way, and I don't think Solr needs
    to work that way be default. I think major numbers are better for
    indicating backwards compat issues than major features with the way
    these projects work. Which is why Yonik mentions 1.5 with weaker back
    compat - its not just the fact that we are going to Lucene 3.x - its
    that Solr still relies on some of the API's that won't be around in 3.x
    - they are not all trivial to remove or to remove while preserving back
    compat.
    The lucene 2.x -> 3.0 upgrade path seems independent of that to me. I
    would even argue that with solr 1.4 we have already required many
    lucene 3.0 changes -- All my custom lucene stuff had to be reworked to
    work with solr 1.4 (tokenizers & multi-reader filters).
    Many - but certainly not all.
    In general, I wonder where the solr back-compatibility contract
    applies (and to what degree). For solr, I would rank the importance as:
    #1 - the URL API syntax. Client query parameters should change as
    little as possible
    #2 - configuration
    #3 - java APIs
    Someone else would likely rank it differently - not everyone using Solr
    even uses HTTP with it. Someone heavily involved in custom plugins might
    care more about that than config. As a dev, I just plainly rank them all
    as important and treat them on a case by case basis.
    With that in mind, i think 'solr 1.5 with lucene 3.x' makes the most
    sense. Unless we see making serious changes to solr that would
    warrent a major release bump.
    What is a serious change that would warrant a bump in your opinion?
    Lucene has an explict back-compatibility contract:
    http://wiki.apache.org/lucene-java/BackwardsCompatibility

    I don't know if solr has one... if we make one, I would like it to
    focus on the URL syntax+configuration
    Its not nice to give people plugins and then not worry about back compat
    for them :)
    ryan


    On Nov 18, 2009, at 5:53 PM, Yonik Seeley wrote:

    What should the next version of Solr be?

    Options:
    - have a Solr 1.5 with a lucene 2.9.x
    - have a Solr 1.5 with a lucene 3.x, with weaker back compat given all
    of the removed lucene deprecations from 2.9->3.0
    - have a Solr 2.0 with a lucene 3.x

    -Yonik
    http://www.lucidimagination.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org

    --
    - Mark

    http://www.lucidimagination.com




    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org
  • Ryan McKinley at Nov 20, 2009 at 1:01 am

    On Nov 19, 2009, at 3:34 PM, Mark Miller wrote:

    Ryan McKinley wrote:
    I would love to set goals that are ~3 months out so that we don't
    have
    another 1 year release cycle. For a 2.0 release where we could have
    more back-compatibly flexibility, i would love to see some work that
    may be too ambitious... In particular, the config spaghetti needs
    some attention.

    I don't see the need to increment solr to 2.0 for the lucene 3.0
    change -- of course that needs to be noted, but incrementing the
    major
    number in solr only makes sense if we are going to change *solr*
    significantly.
    Lucene major numbers don't work that way, and I don't think Solr needs
    to work that way be default. I think major numbers are better for
    indicating backwards compat issues than major features with the way
    these projects work. Which is why Yonik mentions 1.5 with weaker back
    compat - its not just the fact that we are going to Lucene 3.x - its
    that Solr still relies on some of the API's that won't be around in
    3.x
    - they are not all trivial to remove or to remove while preserving
    back
    compat.
    I confess I don't know the details of the changes that have not yet
    been integrated in solr -- the only lucene changes I am familiar with
    is what was required for solr 1.4.



    The lucene 2.x -> 3.0 upgrade path seems independent of that to
    me. I
    would even argue that with solr 1.4 we have already required many
    lucene 3.0 changes -- All my custom lucene stuff had to be reworked
    to
    work with solr 1.4 (tokenizers & multi-reader filters).
    Many - but certainly not all.
    Just my luck... I'm batting 1000 :)

    But that means my code can upgrade to 3.0 without a issue now!

    In general, I wonder where the solr back-compatibility contract
    applies (and to what degree). For solr, I would rank the
    importance as:
    #1 - the URL API syntax. Client query parameters should change as
    little as possible
    #2 - configuration
    #3 - java APIs
    Someone else would likely rank it differently - not everyone using
    Solr
    even uses HTTP with it. Someone heavily involved in custom plugins
    might
    care more about that than config. As a dev, I just plainly rank them
    all
    as important and treat them on a case by case basis.
    I think it is fair to suggest that people will have the most stable/
    consistent/seamless upgrade path if you stick to the HTTP API (and by
    extension most of the solrj API)

    I am not suggesting that the java APIs are not important and that back-
    compatibly is not important. Solr has a some APIs with a clear
    purpose, place, and intended use -- we need to take these very
    seriously. We also have lots of APIs that are half baked and loosy
    goosy. If a developer is working on the edges, i think it is fair to
    expect more hickups in the upgrade path.

    With that in mind, i think 'solr 1.5 with lucene 3.x' makes the most
    sense. Unless we see making serious changes to solr that would
    warrent a major release bump.
    What is a serious change that would warrant a bump in your opinion?
    for example:
    - config overhaul. detangle the XML from the components. perhaps
    using spring.
    - major URL request changes. perhaps we change things to be more
    RESTful -- perhaps let jersey take care of the URL/request building https://jersey.dev.java.net/
    - perhaps OSGi support/control/configuration

    Lucene has an explict back-compatibility contract:
    http://wiki.apache.org/lucene-java/BackwardsCompatibility

    I don't know if solr has one... if we make one, I would like it to
    focus on the URL syntax+configuration
    Its not nice to give people plugins and then not worry about back
    compat
    for them :)
    i want to be nice. I just think that a different back compatibility
    contract applies for solr then for lucene. It seems reasonable to
    consider the HTTP API, configs, and java API independently.

    From my perspective, saying "solr 1.5 uses lucene 3.0" implies
    everything a plugin developer using lucene APIs needs to know about
    the changes.

    To be clear, I am not against bumping to solr 2.0 -- I just have high
    aspirations (yet little time) for what a 2.0 bump could mean for solr.

    ryan


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org
  • Noble Paul നോബിള്‍ नोब्ळ् at Nov 20, 2009 at 5:45 am

    On Fri, Nov 20, 2009 at 6:30 AM, Ryan McKinley wrote:
    On Nov 19, 2009, at 3:34 PM, Mark Miller wrote:

    Ryan McKinley wrote:
    I would love to set goals that are ~3 months out so that we don't have
    another 1 year release cycle.  For a 2.0 release where we could have
    more back-compatibly flexibility, i would love to see some work that
    may be too ambitious...  In particular, the config spaghetti needs
    some attention.

    I don't see the need to increment solr to 2.0 for the lucene 3.0
    change -- of course that needs to be noted, but incrementing the major
    number in solr only makes sense if we are going to change *solr*
    significantly.
    Lucene major numbers don't work that way, and I don't think Solr needs
    to work that way be default. I think major numbers are better for
    indicating backwards compat issues than major features with the way
    these projects work. Which is why Yonik mentions 1.5 with weaker back
    compat - its not just the fact that we are going to Lucene 3.x - its
    that Solr still relies on some of the API's that won't be around in 3.x
    - they are not all trivial to remove or to remove while preserving back
    compat.
    I confess I don't know the details of the changes that have not yet been
    integrated in solr  -- the only lucene changes I am familiar with is what
    was required for solr 1.4.



    The lucene 2.x -> 3.0 upgrade path seems independent of that to me.  I
    would even argue that with solr 1.4 we have already required many
    lucene 3.0 changes -- All my custom lucene stuff had to be reworked to
    work with solr 1.4 (tokenizers & multi-reader filters).
    Many - but certainly not all.
    Just my luck...  I'm batting 1000 :)

    But that means my code can upgrade to 3.0 without a issue now!

    In general, I wonder where the solr back-compatibility contract
    applies (and to what degree).  For solr, I would rank the importance as:
    #1 - the URL API syntax.  Client query parameters should change as
    little as possible
    #2 - configuration
    #3 - java APIs
    Someone else would likely rank it differently - not everyone using Solr
    even uses HTTP with it. Someone heavily involved in custom plugins might
    care more about that than config. As a dev, I just plainly rank them all
    as important and treat them on a case by case basis.
    I think it is fair to suggest that people will have the most
    stable/consistent/seamless upgrade path if you stick to the HTTP API (and by
    extension most of the solrj API)

    I am not suggesting that the java APIs are not important and that
    back-compatibly is not important.  Solr has a some APIs with a clear
    purpose, place, and intended use -- we need to take these very seriously.
    We also have lots of APIs that are half baked and loosy goosy.  If a
    developer is working on the edges, i think it is fair to expect more hickups
    in the upgrade path.

    With that in mind, i think 'solr 1.5 with lucene 3.x' makes the most
    sense.  Unless we see making serious changes to solr that would
    warrent a major release bump
    solr 1.5 with lucene 3.x is a good option.
    Solr 2.0 can have non-back compat changes for Solr itself. e.g
    removing the single core option , changing configuration, REST Api
    changes etc
    What is a serious change that would warrant a bump in your opinion?
    for example:
    - config overhaul.  detangle the XML from the components.  perhaps using
    spring.
    This is already done. No components read config from xml anymore SOLR-1198
    - major URL request changes.  perhaps we change things to be more RESTful --
    perhaps let jersey take care of the URL/request building
    https://jersey.dev.java.net/
    - perhaps OSGi support/control/configuration

    Lucene has an explict back-compatibility contract:
    http://wiki.apache.org/lucene-java/BackwardsCompatibility

    I don't know if solr has one...  if we make one, I would like it to
    focus on the URL syntax+configuration
    Its not nice to give people plugins and then not worry about back compat
    for them :)
    i want to be nice.  I just think that a different back compatibility
    contract applies for solr then for lucene.  It seems reasonable to consider
    the HTTP API, configs, and java API independently.

    From my perspective, saying "solr 1.5 uses lucene 3.0" implies everything a
    plugin developer using lucene APIs needs to know about the changes.

    To be clear, I am not against bumping to solr 2.0 -- I just have high
    aspirations (yet little time) for what a 2.0 bump could mean for solr.

    ryan


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org


    --
    -----------------------------------------------------
    Noble Paul | Principal Engineer| AOL | http://aol.com

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupjava-dev @
categorieslucene
postedNov 19, '09 at 1:53a
activeNov 20, '09 at 5:45a
posts10
users6
websitelucene.apache.org

People

Translate

site design / logo © 2022 Grokbase