FAQ
I just talked to Robert about refactoring of smartcn for the next
releases > 2.9. Robert raised a question if we should mark smartcn as
experimental so that we can change interfaces and public methods etc.
during the refactoring. Would that make sense for 2.9 or is there no
such thing as a back compat policy for modules like that.

simon

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

Search Discussions

  • Mark Miller at Aug 26, 2009 at 2:50 pm

    Simon Willnauer wrote:
    I just talked to Robert about refactoring of smartcn for the next
    releases > 2.9. Robert raised a question if we should mark smartcn as
    experimental so that we can change interfaces and public methods etc.
    during the refactoring. Would that make sense for 2.9 or is there no
    such thing as a back compat policy for modules like that.

    simon

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org
    Contrib modules are not required to support back compat in any way
    currently - but they can also each have any more restrictive policy that
    we want. I consider Highlighter to be 1.4 right now (even though thats
    not explicit anywhere).

    Warning users that you don't plan on promising back compat with
    experimental warnings seems like a good idea to me.

    --
    - 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
  • Simon Willnauer at Aug 26, 2009 at 3:15 pm

    On Wed, Aug 26, 2009 at 4:49 PM, Mark Millerwrote:
    Simon Willnauer wrote:
    I just talked to Robert about refactoring of smartcn for the next
    releases > 2.9. Robert raised a question if we should mark smartcn as
    experimental so that we can change interfaces and public methods etc.
    during the refactoring. Would that make sense for 2.9 or is there no
    such thing as a back compat policy for modules like that.

    simon

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org
    Contrib modules are not required to support back compat in any way
    currently - but they can also each have any more restrictive policy that
    we want. I consider Highlighter to be 1.4 right now (even though thats
    not explicit anywhere).

    Warning users that you don't plan on promising back compat with
    experimental warnings seems like a good idea to me.
    I think so too - done!

    simon
    --
    - 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
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: java-dev-help@lucene.apache.org
  • Chris Hostetter at Aug 27, 2009 at 2:05 pm
    : releases > 2.9. Robert raised a question if we should mark smartcn as
    : experimental so that we can change interfaces and public methods etc.
    : during the refactoring. Would that make sense for 2.9 or is there no
    : such thing as a back compat policy for modules like that.

    http://wiki.apache.org/lucene-java/BackwardsCompatibility
    ...
    Contrib Packages

    "All contribs are not created equal."

    The compatibility commitments of a contrib package can vary based on it's
    maturity and intended usage. The README.txt file for each contrib should
    identify it's approach to compatibility. If the README.txt file for a
    contrib package does not address it's backwards compatibility commitments
    users should assume it does not make any compatibility commitments.



    -Hoss


    ---------------------------------------------------------------------
    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
groupdev @
categorieslucene
postedAug 26, '09 at 2:46p
activeAug 27, '09 at 2:05p
posts4
users3
websitelucene.apache.org

People

Translate

site design / logo © 2021 Grokbase