I think that it might be good to define 3 levels:
fundamental - what all programs probably will use
useful - what many programs might use
and
contrib - mostly examples and code that is not quite ready to be
classed as useful
On Jun 16, 2006, at 6:03 PM, Chris Hostetter wrote:
Are there any written (or unwritten) guidelines on when something
should
be commited to the core code base vs when a contrib module should
be used?
Obviously if a new feature rquires changing APIs omodifying one of the
existing core classes, then that kind of needs to be in the core --
and
there is precidence for the idea thatlangauge specific analyzers
should go
in contrib; and then of course there are things like the Span queries
which seem like htey would have been a prime canidate for a contrib
module
but they aren't (possibly just because when they were added there
was no
"contrib" -- just the sandbox, and it didn't rev with lucene core).
...But I'm just wondering if as we move forward, there should be some
sated policy "unless there is a specific reason why it must be in the
core, put it in a contrib" to help keep the core small -- or if i'm
wrong
about hte general sentiment of the Lucene core.
(FYI: my impedus for asking this question is LUCENE-406 -- I think
it's a
pretty handy feature that everyone might want, but that doesn't
mean it's
not just as usefull commited in contrib/miscellaneous)
-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]
