No one really responded to this Shai? And I take it that the user list
never saw it?
Perhaps we should just ask for opinion from the user list based on what
you already have - just to gauge the reaction on different points.
Unless someone responds shortly, we could take a year waiting to
Well .. to be honest I haven't monitored java-user for quite some time, so I
don't know if it hasn't been raised there.
But now there's the other thread that Yonik started, so I'm not really sure
where to answer.
I think that if we look back at 2.0 and compare to 2.9, anyone upgrading
from that
Right - I'd actually hold off now. I figured the threat of sending might
prompt some action ;)
It still wouldn't hurt to know what the users think, perhaps at more
digestible, overview level though.
I do think Yonik torpedoed something this liberal :)
Thats not a bad thing though. We will
As far as I understand the policy-making process, someone from PMC has
to start the vote, and then PMC members should, well, vote.
Without them taking action we can beep to our hearts' content
without any consequences.
On Sat, May 30, 2009 at 07:22, Shai Erera ser...@gmail.com wrote:
So ... I've
I think the last piece that is needed is to ask on java-user what
others think. In order to do that, I think it needs to be boiled down
to a couple paragraphs.
-Grant
On May 29, 2009, at 11:22 PM, Shai Erera wrote:
So ... I've this happen a lot of times (especially in my thesis
work) -
Actually, I think this is a common, and in fact natural/expected
occurrence in open-source. When a tricky topic is discussed, and the
opinions are often divergent, frequently the conversation never
converges to a consensus and the discussion dies. Only if
discussion reaches a semblance of
I think one conclusion that did come of this discussion was that bugs
should be fixed even if it breaks backward compatibility.
-- DM
On May 30, 2009, at 7:21 AM, Michael McCandless wrote:
Actually, I think this is a common, and in fact natural/expected
occurrence in open-source. When a
Ok, so digging back in this thread, I think the following proposals were
made (if I missed some, please add them):
1. API deprecation last *at least* one full minor release. Example: if we
deprecate an API in 2.4, we can remove it in 2.5. BUT, we are also free to
keep it there and remove it in
So ... I've this happen a lot of times (especially in my thesis work) -
someone raises a controversial topic, or one that touches the nervous of the
system, there's a flurry of activity and then it dies unexpectedly, even
though it feels to everyone that there's an extra mile that should be
taken
So, here's a real, concrete example of the need for case by case back
compat. See https://issues.apache.org/jira/browse/LUCENE-1662
It's completely stupid that ExtendedFieldCache even exists. It is a
dumb workaround for a made up problem that has nothing to do with real
coders living in
OK thanks Shai!
Mike
On Mon, May 25, 2009 at 12:18 AM, Shai Erera ser...@gmail.com wrote:
Yes - 1630.
I'll check 1601 and if nothing's left to do I'll cancel/close it
On Sun, May 24, 2009 at 11:25 PM, Michael McCandless
luc...@mikemccandless.com wrote:
Actually, under LUCENE-1601, what
One thing I don't fully understand about actsAsVersion (and I know it was
said that we may want to drop that approach) - for how long does it stay? I
mean, let's take the invalidAcronym. It is a change in back-compat, yes. But
for how long are we expected to support it? And if we decide to support
On Sun, May 24, 2009 at 2:20 AM, Shai Erera ser...@gmail.com wrote:
One thing I don't fully understand about actsAsVersion (and I know it was
said that we may want to drop that approach) - for how long does it stay? I
mean, let's take the invalidAcronym. It is a change in back-compat, yes. But
I'm tempted to simply make that change by default for 2.9, now.
Agree !
Shai
On Sun, May 24, 2009 at 1:28 PM, Michael McCandless
luc...@mikemccandless.com wrote:
On Sun, May 24, 2009 at 2:20 AM, Shai Erera ser...@gmail.com wrote:
One thing I don't fully understand about actsAsVersion
I'll open an issue for this and we can discuss under there.
And I still need to open issues for the other change defaluts in my
original email.
Mike
On Sun, May 24, 2009 at 8:11 AM, Shai Erera ser...@gmail.com wrote:
I'm tempted to simply make that change by default for 2.9, now.
Agree !
I created LUCENE-1601 for that purpose with a fix-version 3.0. I noticed you
already opened another issue for the scoring only. So we should remove it
from there (note that there's a TODO in the code, if you plan to change it
in the new issue you opened). 1601 will still handle the new method
Actually, under LUCENE-1601, what more was there to do besides turning
off scoring when sorting by field, by default?
Is there an issue for adding mating Scorer.scoresDocsInOrder
Collector.acceptsDocsOutOfOrder?
Mike
On Sun, May 24, 2009 at 3:22 PM, Shai Erera ser...@gmail.com wrote:
I
Yes - 1630.
I'll check 1601 and if nothing's left to do I'll cancel/close it
On Sun, May 24, 2009 at 11:25 PM, Michael McCandless
luc...@mikemccandless.com wrote:
Actually, under LUCENE-1601, what more was there to do besides turning
off scoring when sorting by field, by default?
Is there
A funny thought: we can give those methods/classes really stupid/nasty names,
to emphasize the beauty of the existing API, to encourage people to stick
with the better API :)
I believe I've seen google using internally names like
thisisbadbadbadInstanceMap. :)
One thing we didn't address
Earwin Burrfoot wrote:
As I said, my app uses around ten indexes, which one should I use? :)
Even more here, this would be a reasonably painful solution for us.
Matt
-
To unsubscribe, e-mail:
Perhaps it is wise to take a step back before we play all of these
what if games...
I think the best way forward is to simply ask ourselves, when
confronted with an actual issue, is what is the cost of back compat.
for this issue and then address it on a case by case basis, with a
bias
OK it sounds like a single global actsAsVersion is too problematic.
So how about, for cases where back compat default settings are
important (analyzers, query scoring changes, etc.) we add
actsAsVersion as a mandatory ctor argument to those classes
(deprecating the other ctors)? We would do this
On Thu, May 21, 2009 at 6:53 PM, Marvin Humphrey mar...@rectangular.com wrote:
Lastly, I think a major java Lucene release is justified already.
Won't this discussion die down somewhat if you can get 3.0 out?
Somewhat, yes, but then when working on 3.1 if we make some great
improvement, I'd
So, iterating on the proposed changes to back-compat policy:
1. If we deprecate an API in the 2.1 release, we can remove it in
the next minor release (2.2).
2. JAR drop-in-ability is only guaranteed on point releases (2.4.1
is a drop-in replacement to 2.4.0). When switching to a
1. If we deprecate an API in the 2.1 release, we can remove it in
the next minor release (2.2).
Agree. Maybe also this?
1a. If deprecated functionality is trivially implemented with new one,
we reserve the right to delete deprecated things right away with
appropriate CHANGES note.
Sample I:
On Fri, May 22, 2009 at 11:53:02AM -0400, Michael McCandless wrote:
1. If we deprecate an API in the 2.1 release, we can remove it in
the next minor release (2.2).
2. JAR drop-in-ability is only guaranteed on point releases (2.4.1
is a drop-in replacement to 2.4.0). When
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.
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
On Fri, May 22, 2009 at 11:33:33AM -0400, Michael McCandless wrote:
when working on 3.1 if we make some great improvement, I'd like new users in
3.1 to see the improvement by default.
Sounds like an argument for more frequent major releases. But I'm not exactly
one to talk. ;)
On
In KinoSearch SVN trunk, satellite classes like QueryParser and Highlighter
have to be passed a Schema, which contains all the Analyzers. Analyzers
aren't satellite classes under this model -- they are a fixed property of a
FullTextType field spec. Think of them as baked into an SQL field
On Fri, May 22, 2009 at 12:52 PM, Marvin Humphrey
mar...@rectangular.com wrote:
when working on 3.1 if we make some great improvement, I'd like new users in
3.1 to see the improvement by default.
Sounds like an argument for more frequent major releases.
Yeah. Or rebranding what we now call
On Fri, May 22, 2009 at 1:22 PM, Michael McCandless
luc...@mikemccandless.com wrote:
(That said, unrelated to this discussion, I would actually like to
record per-segment which version of Lucene wrote the segment; this
would be very helpful when debugging issues like LUCENE-1474 where I
need
On Fri, May 22, 2009 at 12:37 PM, Marvin Humphrey
mar...@rectangular.com wrote:
I still like per-class settings classes. For instance, an IndexWriterSettings
class which allows you to hide away all the tweaky stuff that's cluttering up
the IndexWriter API.
IndexWriterSettings settings =
Yonik Seeley wrote:
On Fri, May 22, 2009 at 1:22 PM, Michael McCandless
luc...@mikemccandless.com wrote:
(That said, unrelated to this discussion, I would actually like to
record per-segment which version of Lucene wrote the segment; this
would be very helpful when debugging issues like
I feel the opposite: I'd like new users to see improvements by
default, and users that require strict back-compate to ask for that.
By strict back-compat, do you mean people who would like their search app to
not fail silently? ;) A new user who follows your advice...
// haha stupid noob
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
On Fri, May 22, 2009 at 01:22:24PM -0400, Michael McCandless wrote:
Sounds like an argument for more frequent major releases.
Yeah. Or rebranding what we now call minor as major releases, by
changing our policy ;)
Not sure how much of that is a jest, bug I don't think that's a good idea.
Michael McCandless wrote:
On Fri, May 22, 2009 at 12:52 PM, Marvin Humphrey
mar...@rectangular.com wrote:
when working on 3.1 if we make some great improvement, I'd like new users in
3.1 to see the improvement by default.
Sounds like an argument for more frequent major releases.
On Fri, May 22, 2009 at 09:06:32PM +0400, Earwin Burrfoot wrote:
In KinoSearch SVN trunk, satellite classes like QueryParser and Highlighter
have to be passed a Schema, which contains all the Analyzers. Analyzers
aren't satellite classes under this model -- they are a fixed property of a
Marvin Humphrey wrote:
I feel the opposite: I'd like new users to see improvements by
default, and users that require strict back-compate to ask for that.
By strict back-compat, do you mean people who would like their search app to
not fail silently? ;) A new user who follows your
On Fri, May 22, 2009 at 2:27 PM, DM Smith dmsmith...@gmail.com wrote:
Marvin Humphrey wrote:
I feel the opposite: I'd like new users to see improvements by
default, and users that require strict back-compate to ask for that.
By strict back-compat, do you mean people who would like their
Custom analyzers.
No problem.
How are they recorded in the index?
Several indexes using the same analyzer.
No problem. Only necessary if the analyzer is costly or has some esoteric
need for shared state. And possible via subclassing Schema or Analyzer.
It is.
Intentionally different
OK, net/net it doesn't look like we're going reach agreement on some
general approach for having users of Lucene always get the best
default settings.
We started with the *Settings classes, but that's really a very large
project (goes far beyond managing defaults for new users).
Then we went to
Michael McCandless wrote:
On Fri, May 22, 2009 at 2:27 PM, DM Smith dmsmith...@gmail.com wrote:
Marvin Humphrey wrote:
I feel the opposite: I'd like new users to see improvements by
default, and users that require strict back-compate to ask for that.
By strict back-compat,
I'd like to do this for 2.9 :) I'll open an issue...
(Yes this would just be for diagnostics).
Mike
On Fri, May 22, 2009 at 1:48 PM, DM Smith dmsmith...@gmail.com wrote:
Yonik Seeley wrote:
On Fri, May 22, 2009 at 1:22 PM, Michael McCandless
luc...@mikemccandless.com wrote:
(That said,
Well... I would expect hope Lucene's adoption is growing with time,
so the number of new users should increase on each release. For a
healthy project that's relatively young compared to its potential user
base, that growth should be exponential.
And, I'd expect the vast majority of old users
Michael McCandless wrote:
Well... I would expect hope Lucene's adoption is growing with time,
so the number of new users should increase on each release. For a
healthy project that's relatively young compared to its potential user
base, that growth should be exponential.
And, I'd expect the
On Fri, May 22, 2009 at 10:40:03PM +0400, Earwin Burrfoot wrote:
Custom analyzers.
No problem.
How are they recorded in the index?
Analyzers must implement dump() and load(), which convert the Analyzer to/from
a JSON-izable data structure. They end up as JSON in
index_dir/schema_NNN.json.
On Fri, May 22, 2009 at 3:37 PM, DM Smith dmsmith...@gmail.com wrote:
So, what is it that they use that leads to such unfavorable results?
I think it's simply that they take each search engine, get it to index
their collection in the most obvious way, perhaps having read a
tutorial somewhere,
OK so it sounds like we've boiled the proposal down to two concrete
changes to the back-compat policy:
1) Default settings can change; we will always choose defaults based
on latest greatest for new users. This only affects runtime
behavior. EG in 2.9, when sorting by field you
I thought that the index file format is supposed to be supported until the
2nd major release. I.e. 3.0 will still read 2.0 indexes, but 4.0 won't. Is
that what you meant, or am I wrong?
Shai
On Thu, May 21, 2009 at 2:17 PM, Michael McCandless
luc...@mikemccandless.com wrote:
OK so it sounds
On May 21, 2009, at 7:17 AM, Michael McCandless wrote:
1) Default settings can change; we will always choose defaults based
on latest greatest for new users. This only affects runtime
behavior. EG in 2.9, when sorting by field you won't get scores
by default. When we do this
On Thu, May 21, 2009 at 8:24 AM, DM Smith dmsmith...@gmail.com wrote:
On May 21, 2009, at 7:17 AM, Michael McCandless wrote:
1) Default settings can change; we will always choose defaults based
on latest greatest for new users. This only affects runtime
behavior. EG in 2.9, when
even as simple as changing default stopword list for some analyzer could be
an issue, if the user doesn't re-index in response to that change.
Can you give an example of such changes? EG if we fix a bug in
StandardAnalyzer, we will default it to fixed for new users and expect
you on
On Thu, May 21, 2009 at 12:19 PM, Robert Muir rcm...@gmail.com wrote:
even as simple as changing default stopword list for some analyzer could be
an issue, if the user doesn't re-index in response to that change.
OK, right.
So say we forgot to include the in the default English stopwords
list
For extreme examples like this, couldn't the stopword list be
encapsulated into a single class that's used by the lucene defaults class.
That way if you folks released updates to mostly static content like a
stopword list, new or old users could get it easily with a simple drop
in fix?
Just
What is the lucene defaults class?
Mike
On Thu, May 21, 2009 at 12:37 PM, Matthew Hall
mh...@informatics.jax.org wrote:
For extreme examples like this, couldn't the stopword list be encapsulated
into a single class that's used by the lucene defaults class.
That way if you folks released
Michael McCandless wrote:
On Thu, May 21, 2009 at 12:19 PM, Robert Muir rcm...@gmail.com wrote:
even as simple as changing default stopword list for some analyzer could be
an issue, if the user doesn't re-index in response to that change.
OK, right.
So say we forgot to include the in
Michael McCandless wrote:
On Thu, May 21, 2009 at 8:24 AM, DM Smith dmsmith...@gmail.com wrote:
On May 21, 2009, at 7:17 AM, Michael McCandless wrote:
1) Default settings can change; we will always choose defaults based
on latest greatest for new users. This only affects runtime
Sorry, I wasn't quite sure what to call this new class you guys have
been talking about.
I was referring to the class that's being discussed to encapsulate all
of the defaults for a given lucene release. (Its caching strategies etc
etc)
I'm just not certain that something like a static
On Thu, May 21, 2009 at 12:43 PM, Mark Miller markrmil...@gmail.com wrote:
Hmmm - thats starting to sound nastier. Its another barrier to upgrading to
a new jar. I have to monitor/hunt down and not miss all these little flags
so that docs/terms don't disappear from my index? There is already
yeah, i was thinking the more likely case of where something like teh is
in the list...
On Thu, May 21, 2009 at 12:25 PM, Michael McCandless
luc...@mikemccandless.com wrote:
On Thu, May 21, 2009 at 12:19 PM, Robert Muir rcm...@gmail.com wrote:
even as simple as changing default stopword list
Actually, we started with the *Settings classes (to hold defaults),
but then realized a simple actsAsVersion (single static method) would
suffice for just the back-compat settings and then pushed further and
thought perhaps we should relax our back-compat policy entirely so
emulating older
Mike McCandless:
Well this is what I love about the actsAsVersion solution. There's no
pain for our back-compat users (besides the one-time effort to set
actsAsVersion), and new users always get the best settings.
When some mad-as-hell user complains to this list after spending an inordinate
That bug has led to 'base' having a compromised reputation among elite users
because of intermittent, inexplicable flakiness. Is that what you want for
Lucene?
While I agree with that point, Lucene already has lots and lots of
static configuration.
Having actsAsVersion won't add any new woes.
I'm having trouble visualizing the various methods people are talking
about. It seems like we could open an issue and post patches with code
illustrating what each person is talking about?
On Thu, May 21, 2009 at 10:02 AM, Michael McCandless
luc...@mikemccandless.com wrote:
Actually, we
I thought we were actually on the track towards not introducing any Settings
and/or actAs, but instead just change the policy?
Can we agree on the following:
* Changes to the index file formats need to be supported for 2 major
releases. I.e. 2.X indexes need to be read by 3.Y code, but not by
Sounds like a good proposition.
There's one problem I'd like to address. Good names for
classes/members matter, and matter much. They directly affect how fast
a newcomer is able to understand that particular API, it also affects
how comfortable you work with it once you did understand. When we're
On Thu, May 21, 2009 at 4:34 PM, Shai Erera ser...@gmail.com wrote:
Changes to the index file formats need to be supported for 2 major releases.
I.e. 2.X indexes need to be read by 3.Y code, but not by 4.0.
Agreed.
Method deprecations last for one full minor release.
Your example confused
Why not store an actsAs in the index, just for the changes that
affect what's in the index? Ie the index records the
version that created it, and by default TokenStreams emulate their
behavior as of that version?
Because you don't always have access to index at the time you create
your
On Thu, May 21, 2009 at 1:59 PM, Marvin Humphrey mar...@rectangular.com wrote:
That bug has led to 'base' having a compromised reputation among elite users
because of intermittent, inexplicable flakiness. Is that what you want for
Lucene?
While I agree a single global default is not great, I
On Thu, May 21, 2009 at 5:19 PM, Earwin Burrfoot ear...@gmail.com wrote:
Why not store an actsAs in the index, just for the changes that
affect what's in the index? Ie the index records the
version that created it, and by default TokenStreams emulate their
behavior as of that version?
and what if your analyzer needs a third-party library (or two)?
i mean this isn't unique to analyzers, if something changes/bug is fixed in
the guts of some query/scorer that affects scoring in the slightest then
thats a potential issue too, right?
for a big index burying a result deep is
On Thu, May 21, 2009 at 5:44 PM, Robert Muir rcm...@gmail.com wrote:
and what if your analyzer needs a third-party library (or two)?
In such cases the back-compat of your analyzer is your responsibility,
right?
i mean this isn't unique to analyzers, if something changes/bug is fixed in
the
On Thu, May 21, 2009 at 5:55 PM, Michael McCandless
luc...@mikemccandless.com wrote:
On Thu, May 21, 2009 at 5:44 PM, Robert Muir rcm...@gmail.com wrote:
and what if your analyzer needs a third-party library (or two)?
In such cases the back-compat of your analyzer is your responsibility,
On 5/21/2009 at 7:17 AM, Michael McCandless wrote:
OK so it sounds like we've boiled the proposal down to two concrete
changes to the back-compat policy:
1) Default settings can change; we will always choose defaults
based on latest greatest for new users. This only
affects
On Thu, May 21, 2009 at 05:19:43PM -0400, Michael McCandless wrote:
Marvin, which solution would you prefer?
Between the two, I'd prefer settings constructor arguments, though I would be
inclined to have settings classes that are specific to individual classes
rather than Lucene-wide.
At
Your example confused me.
You're right. I Wrote it with one eye closed already. I meant to say that if
I'm a 2.4 user and something gets deprecated in trunk (afterwards), it is
carried through 2.4.X and 2.5 and then removed in 2.6. So only 1 full minor
release.
It's somewhat crazy, but what
On May 19, 2009, at 1:51 PM, Michael McCandless wrote:
I think you've moved onto discussing something different: should we
relax our back compat policy. I'm all for that discussion, but it's
different from given our back compat policy, how can we implement it
w/o harming new users of Lucene.
On Tue, May 19, 2009 at 4:50 PM, Yonik Seeley
yo...@lucidimagination.com wrote:
Right, that's exactly why I want to fix it (only one behavior allowed
and so for all of 2.* we must match the 2.0 behavior).
I meant one jar per per-jvm gives you one behavior (as is the case now).
But by setting
Michael McCandless wrote:
On Tue, May 19, 2009 at 4:50 PM, Yonik Seeley
yo...@lucidimagination.com wrote:
Right, that's exactly why I want to fix it (only one behavior allowed
and so for all of 2.* we must match the 2.0 behavior).
I meant one jar per per-jvm gives you one behavior
On Wed, May 20, 2009 at 7:22 AM, Michael McCandless
luc...@mikemccandless.com wrote:
So I think you're suggesting something like this: when you use Lucene,
if you want latest and greatest defaults, do nothing.
If instead you want defaults to match a particular past minor release,
you must
I like the idea of settings however it is implemented. With the
blurring of core and contrib in the repackaging of Lucene, the issue
of backward compatibility becomes more difficult. (maybe, I'm
imagining problems where they don't exist.)
My concern with any of these mechanisms: codifying
On Wed, May 20, 2009 at 8:28 AM, Yonik Seeley
yo...@lucidimagination.com wrote:
So I think you're suggesting something like this: when you use Lucene,
if you want latest and greatest defaults, do nothing.
If instead you want defaults to match a particular past minor release,
you must call
But since 3.0 is a major release anyway, we could change the default
of actsAsVersion with each 3.x release (or just set it to 3) and
require that a users set actsAsVersion=3 (or whatever version they
are on) in order to get maximum back compatibility.
What happens when two libraries
Exactly what happens when you call BooleanQuery.setMaxClauseCount(n)
from two libraries.
Last one wins.
On Wed, May 20, 2009 at 17:50, Marvin Humphrey mar...@rectangular.com wrote:
But since 3.0 is a major release anyway, we could change the default
of actsAsVersion with each 3.x release (or
On Wed, May 20, 2009 at 05:57:49PM +0400, Earwin Burrfoot wrote:
What happens when two libraries loaded in the same VM have Lucene as a
dependency and set actsAsVersion to conflicting numbers?
Exactly what happens when you call BooleanQuery.setMaxClauseCount(n)
from two libraries.
Last
Marvin Humphrey wrote:
Yeesh, that's evil. :(
It will be sweet, sweet justice if one of your own projects gets infected by
the kind of action-at-a-distance bug you're so blithely unconcerned about
Heh. Thats a bit over the top. It is evil stuff, but its much less evil
in this very contained
On Wed, 20 May 2009, Michael McCandless wrote:
On Wed, May 20, 2009 at 11:57 AM, Yonik Seeley
yo...@lucidimagination.com wrote:
On Wed, May 20, 2009 at 11:46 AM, Mark Miller markrmil...@gmail.com wrote:
Marvin Humphrey wrote:
Yeesh, that's evil. :(
It will be sweet, sweet justice if one
On Wed, May 20, 2009 at 11:57 AM, Yonik Seeley
yo...@lucidimagination.com wrote:
On Wed, May 20, 2009 at 11:46 AM, Mark Miller markrmil...@gmail.com wrote:
Marvin Humphrey wrote:
Yeesh, that's evil. :(
It will be sweet, sweet justice if one of your own projects gets infected
by
the kind
On Wed, May 20, 2009 at 12:55 PM, Andi Vajda va...@osafoundation.org wrote:
I've been watching this thread with interest with my opinion swaying back
and forth.
So have I!
This last comment, though, pushes me to favor the settings class idea
because that idea came with the promise of
On Wed, May 20, 2009 at 11:46 AM, Mark Miller markrmil...@gmail.com wrote:
Marvin Humphrey wrote:
Yeesh, that's evil. :(
It will be sweet, sweet justice if one of your own projects gets infected
by
the kind of action-at-a-distance bug you're so blithely unconcerned about
Heh. Thats a bit
Then why go through all this trouble and not simply change the back-compat
policy?
Really, I read some of Grant's responses and I realize that I've upgraded to
2.4 way too long ago. 2.9 is nowhere in sight. It takes a lot of time to
release and during that time there's lots of discussions on the
In fact, there's no reason to upgrade Lucene (save for bigfixes), if
you absolutely require a drop-in jar, and don't want to touch any of
your code.
See, you upgrade either for new features, or for performance
improvements. You have to write code for former, and you have to write
code for the
Earwin Burrfoot wrote:
See, you upgrade either for new features, or for performance
improvements. You have to write code for former, and you have to write
code for the latter (because by default most of them are off).
Thats not completely true. If you have upgraded Lucene over the years
and
Exactly ! which is why I think we should relax the back-compat policy a
bit.
And ... (I realize it's going to complicate things a bit) we could also
decide to have dot release for bug fixes, like we had 2.4.1. So let's say
when 3.4 comes (3-4 years from now :) ). In 3.6 we don't preserve any
Mark Miller:
If you have upgraded Lucene over the years and you never touched code to
tweak performance, you still got fantastic performance improvements. You just
didn't get them all.
If you never touched the code over the years, your project is probably
already dead.
Shai Erera:
Exactly !
On Wed, May 20, 2009 at 3:24 PM, Shai Erera ser...@gmail.com wrote:
Then why go through all this trouble and not simply change the back-compat
policy?
OK so let's talk policy now ;)
We need some serious relaxing of the back-compat policy to make the
actsAsVersion proposal pointless.
Ie
Earwin - I wrote it before - index structure is the only back-compat policy
I propose to keep, and not for just one major release, but for 2 (which I
believe is the current behavior already). I also absolutely don't want to
give that up.
I think it's not unreasonable to say if you want to take
Earwin Burrfoot wrote:
See, you upgrade either for new features, or for performance
improvements. You have to write code for former, and you have to write
code for the latter (because by default most of them are off).
Mark Miller:
If you have upgraded Lucene over the years and you never
Shai Erera wrote:
+1 (am I allowed to cast +1s not being a committer?) :)
Absolutely :) When push comes to shove, you don't even have a valid vote
as a Committer. Only members of the PMC have binding votes.
You have as much voting power as a committer as long as you have as much
an ability
1 - 100 of 142 matches
Mail list logo
