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.
Yeah. Or "rebranding" what we now call minor as major releases, by
changing our policy ;) Or "rebranding" to Lucene 2009.
But: localized improvements (like the sizable performance gain from
turning off scoring when sorting by field) should not have to wait for
a major release to benefit new users. I think they should be on by
default on the next release.
This proposed policy change of allowing backward compatibility in the
API to change within a major release is nothing more than smoke and
mirrors. But I see two side effects:
1) Debian, Fedora, and perhaps other Linux distributions, see minor
releases as maintaining backward compatibility. With Debian, they bump
their major revision number with each break in backward compatibility. I
didn't check, but my guess is that the version name of Lucene in Debian
corresponds with that of Lucene itself. I'd hate for that to change. How
would you like to see Debian to name it Lucene 4 or Lucene 5, when we
are doing Lucene 3.x. It gets confusing. (Real example: libsword7,
which corresponds to the 1.5.11 release of SWORD and libsword8
corresponds to 1.6.0.)
2) Backward compatibility of the index is at least 2 major revisions and
that is not proposed to change. Now with this, we effectively postpone
it indefinitely. Rather than the index being allowed to change when the
API has broken compatibility at most 2 times, with this proposed change,
we can break API compatibility a dozen times. At the future point where
this policy is brought into question, with something like "Now that we
can break backward compatibility in the API frequently, we need to
change our policy for the index to match", then we will have come full
circle.
At first, I liked the idea a lot, but now less so. Now I'm leaning
toward changing major revision number when backward compatibility
changes and for more frequent major releases if that is what it takes.
This was the thrust of my tongue-in-cheek proposal of weekly minor and
monthly major releases.
I also share Marvin's and others' concerns about sneaky bugs introduced
by globals. In my situation, Lucene is part of a desktop application and
the user can create hundreds of indexes and use them within the
application. With a *.deb or *.rpm, we'll have to specify that they
cannot use anything but the minor release for which the application was
designed. Before, we could say that one could drop in anything of the
same major release number.
I don't think I am alone or unique in embedding Lucene into a desktop
application. I know it is a part of Eclipse (at least on Fedora).
This change might have the opposite effect of making people's perception
of Lucene as one of instability. Guard carefully against that, please!
-- DM
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
