I'm not against back compatibility. In fact, I agree with your
points, especially the use of the phrase "commonly used interfaces".
My main problem is our approach seems to be very dogmatic and
detrimental for _less_ commonly used interfaces (more importantly less
commonly _implemented_ Interfaces) and it creates a whole lot of cruft
in the code. Code that is only released every 6-12 months anyway.
Specific examples include:
1. Fieldable
2. FieldCache and ExtendedFieldCache
3. The five gazillion IndexWriter constructors
4. The Analyzer.tokenStream stuff.
The thing is, we have this false sense about back compatibility
anyway. We think we are doing it, but time and again it slips through
because there is _NO WAY_ we can know all of the myriad of uses of
Lucene. My take: be strict about index compatibility, take API
changes on a case-by-case basis, favoring _preserving_ back
compatibility unless it is too expensive. Communicate any changes
loudly.
So, yes, back compatibility as part of a pragmatic approach that
recognizes our release timeframes and the ability for modern IDEs to
help in refactoring is good. Back compatibility for the sake of back
compatibility is harmful and will ultimately be the downfall of
Lucene, IMO, because it won't keep up simply because it will take
twice as long to develop new ways of doing things and it will scare
away new contributors who can't possibly fathom all of the back
compatibility requirements (heck, us committers who have been around
for a long time can't even do it).
At any rate, I also am promoting the case by case approach. And I
will kick it off by opening an issue that gets rid of the stupid
ExtendedFieldCache abomination and breaks the FieldCache back compat.
interface construct.
-Grant
On Jun 10, 2009, at 1:00 PM, Yonik Seeley wrote:
I'm starting to feel like the lone holdout that thinks back compat for
commonly used interfaces and index formats is important. So I'll sum
up some of my thoughts and leave it at that:
- I doubt that the number of new users for each release of Lucene
exceeds the sum total of all existing users of Lucene. Lucene is
already the dominant open source search library, so we're never going
to hit that type of exponential growth going forward. Existing users
are very important.
- Good back compat makes the lives of all Lucene users easier
- Good back compat makes the lives of Lucene developers easier in some
ways also. We don't *need* to go back and patcholder releases, since
we can say "use a newer release". If things change too much, that
will no longer be an easy option for many users, and more people will
get stuck in the past because upgrading is too painful.
- The difficulty of change can also be a good thing - it forces people
to really think if changes are worth it and only add them where it
really makes sense.
The last threads on back compat generated so much volume that I
couldn't keep up, and I expect there are many others that couldn't
either. I'm not personally interested in discussing it in the
abstract further... I'm more interested in actual code
patches/proposals.
-Yonik
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
