On Fri, May 22, 2009 at 12:44 PM, Yonik Seeley
<yo...@lucidimagination.com> wrote:
> I'm not a lawyer, so I dislike trying to nail down every detail in
> writing and try to solve future problems in the abstract.
Agreed, and there's always leeway in what we work out here
(LUCENE-1436 is a good recent example), but I think working out broad
guidelines for us to follow is still worthwhile. EG I think the
existing guidelines have served us well (in that it's something to
follow when working on changes).
> Lucene has never really been 100% back compatible... we've just tried
> to keep it that way... it's more of a mindset than a reality, and I'm
> wary of changing that mindset too much. Lucene has benefited from API
> and design stability, and I think the bar should be kept high for
> changes (i.e. there should be clear benefits).
>
> Anyway, I think substantially relaxing back compat requirements is
> enough of a change that it should at some point go to a vote (once
> people figure out exactly what is being voted on ;-)
Definitely, if we can actually figure out what to vote on, we should
vote on this change...
> That doesn't apply to a static actsAsVersion that would preserve back
> compatibility by default of course.
Actually I was wanting by default to *not* preserve back compat. Ie,
new users see Lucene's latest & greatest for free; old users must set
back-compate level.
> Depending on the specifics, it may often be simpler/cleaner to create
> a new class / constructor and deprecate the old, as we do now.
True, and actually this is a viable workaround/fallback if we can't
otherwise come to agreement, to let new users see the best of Lucene
by default.
So eg we could deprecate:
public TopFieldDocs search(Query query, Filter filter, int n,
Sort sort)
and add:
public TopFieldDocs search(Query query, Filter filter, int n,
Sort sort, boolean includeScores)
(or something along those lines).
Or, deprecate IndexReader.open in favor of open(boolean readOnly).
It's not an unreasonable approach, in that whenever there is a setting
that needs to change in a given release, we simply make it explicit.
Though this is more awkward for bug fixes to StandardAnalyzer (for
example). What would the new ctor look like? I guess you'd pass in
the "invalidAcronyms" to the ctor.
>> 4. [Maybe?] Allow certain limited changes that will require source
>> code changes in your app on upgrading to a new minor release:
>> adding a new method to an interface, adding a new abstract method
>> to an abstract class, renaming of deprecated methods.
>
> +1, depending on the specifics. This is where back compat rules
> shouldn't be cast in stone.
> There are some public classes in Lucene that are really just
> implementation artifacts - pretty much no one will directly use those
> classes and changes to those shouldn't be a big deal.
Right.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
