[
https://issues.apache.org/jira/browse/LUCENE-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079676#comment-14079676
]
Robert Muir commented on LUCENE-5858:
-------------------------------------
If people really want a separate jar, then fine.
BUT
we remove them from the normal "rotation" so core testing has a clean classpath
and we can remove even more cruft (like packed ints). These days, we have
dedicated TestXXXFormat for every codec, so this is not really needed anymore,
instead just an annoyance: wasted time debugging test failures that are just
quirks in old behavior of ancient codecs (e.g. not supporting missing values),
and false jenkins failures because newer features arent supported (causing tons
of SuppressCodecs everywhere). I think it made sense for the initial 3.x->4.x
cutover, we didn't have such a mechanism for testing at that point, nor did we
have really so many new index features that various search functionality was
trying to use: blasting them thru all the tests was our only choice. But I
think these days it does more harm than good. Most of the old formats we are
still testing (like 3.0) are years and years old and just don't support the
modern features. We should be looking forwards instead of backwards.
My motivation here is to make backwards compatibility simpler and less of a
hassle for us as a project, not more difficult and more complex.
> Move back compat codecs out of core/ into codecs/ jar
> -----------------------------------------------------
>
> Key: LUCENE-5858
> URL: https://issues.apache.org/jira/browse/LUCENE-5858
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
>
> These take significant space and bloat core lucene. Not everyone needs the
> ability to read ancient indexes (especially building a new app).
> We should move this cruft out of the core/ jar. codecs/ is the obvious place,
> its already setup in the build system for tests and everything else.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
