I don't think I can say that this needs to happen now either. :)
An interesting question to answer would be:
If Lucene did not exist, and given all of the knowledge we have, we
decided to create a Java based search engine, would the API look like
it does today?
The answer may be yes. I doubt it would be in many areas though.
The major releases are where you get to rethink the API and the
approach.
If you don't do this, Lucene will slowly die (as you stated). What
happens is that the developers get tired of the harness and start a
new project. If the API were able to be changed easier this would
not happen.
On Jan 23, 2008, at 4:27 PM, Michael McCandless wrote:
robert engels wrote:
I think you are incorrect.
I would guess the number of people/organizations using Lucene vs.
contributing to Lucene is much greater.
The contributers work in head (should IMO). The users can select a
particular version of Lucene and code their apps accordingly. They
can also back-port features from a later to an earlier release. If
they have limited development resources, they are probably not
working on Lucene (they are working on their apps), but they can
update their own code to work with later versions - which they
would probably rather do than learning the internals and
contributing to Lucene.
If the users are "just dropping in a new version" they are not
contributing to the community... I think just the opposite, they
are parasites. I think a way to gauge this would be the number of
questions/people on the user list versus the development list.
I don't think they are parasites at all. They are users that place
alot of trust in us and will come to the users list with
interesting issues. Many of the improvements to Lucene are sourced
from the users list. Even if that user doesn't do the actual work
to fix the issue, their innocent question and prodding can inspire
someone else to take the idea forward, make a patch, etc. This is
the normal and healthy way that open source works....
Lucene is a library, and I believe what I stated is earlier is
true - in order to continue to advance it the API needs to be
permitted to change to allow for better functionality and
performance. If Lucene is hand-tied by earlier APIs then this work
is either not going to happen, or be very messy (inefficient).
The thing is, we have been able to advance lately, sizably, without
breaking APIs, thanks to the "future backwards compatibility
proofing" that Lucene does.
I do agree that if it got to the point where we were forced to make
a hard choice of stunt Lucene's growth so as to keep backwards
compatibility vs let Lucene grow and make a new major release, we
should definitely make a new major release. Search is still young
and if we stunt Lucene now it will slowly die.
It's just that I haven't seen any recent change, except for
allowing JVM 1.5 source, that actually requires a major release, I
think.
Mike
On Jan 23, 2008, at 3:40 PM, Chris Hostetter wrote:
: I guess I don't see the back-porting as an issue. Only those
that want to need
: to do the back-porting. Head moves on...
I view it as a potential risk to the overal productivity of the
community.
If upgrading from A to B is easy people (in general) won't spend
a lot of
time/effort backporting feature from B to A -- this time/effort
savings
benefits the community because (depending on the person):
1) that time/effort saved can be spend contributing even more
features
to Lucene
2) that time/effort saved improves the impressions people have
of Lucene.
If on the other hand upgrading from X to Y is "hard" that
encouragees
people to backport features ... in some cases this backporting
may be done
"in the open" with people contributing these backports as
patches, which
can then be commited/releaseed by developers ... but there is
still a
time/effort cost there ... a bigger time/effort cost is the
cummulative
time/effort cost of all the people that backport some set of
features just
enough to get things working for themselves on their local copy,
and don't
contribute thouse changes back ... that cost gets paid by the
commuity s a
whole over and over again.
I certianly don't want to discourage anyone who *wants* to backport
features, and I would never suggest that Lucene should make it a
policy to
not accept patches to previous releases that backport
functionality -- i
just think we should do our best to minimize the need/motivation
to spend
time/effort on backporting.
-Hoss
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
