Currently the Lucene development team is working on
categorizing change requests into core and non-core
changes.
Core changes would entail a change to the search engine
core itself. From Doug Cutting:
"Examples include: file locking to make things
multi-process safe; adding an API for boosting individual documents and fields
values; making the scoring API extensible and public; etc."
Non-core changes would not affect the search engine
itself, but would consist instead of projects or components that would
make useful
additions to the core framework. Again, from Doug
Cutting:
"[Examples] include: support for more languages; query
parsers; database storage; crawlers, etc. Whether these belong in the
base distribution is a matter of debate (sometimes hot). My rule of
thumb for including them is their generality: if they are likely to be
useful to a large proportion of Lucene users then they should probably go
in the base distribution. Language support in particular is tricky.
Perhaps we should migrate to a model where the base distribution
includes no analyzers, and supply separate language packages."
Change requests will be categorically defined by the
development team (committers) as core or non-core, and a committer will
be assigned responsibility for
coordinating development of the change request. All
change requests should be submitted to one of the Lucene mailing lists, or
through
the Apache
Bugzilla database.
