[
https://issues.apache.org/jira/browse/LUCENE-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17276575#comment-17276575
]
Michael Sokolov commented on LUCENE-9705:
-----------------------------------------
Just throwing this out there; I have no real proposal, just a feeling, but it
seems very heavyweight that we create a new package and new java classes every
time we change our index format. It's especially clear here where we must copy
a lot of classes with no change at all, merely to clearly and consistently
document the index version change. I noticed that we also have to copy (and
slightly change) the package-level javadocs when we do this, and this has been
done pretty inconsistently over time.
I wonder if we (eventually) should consider shifting to a versioning system
that doesn't require new classes. Is this somehow a feature of the service
discovery API that we use?
> Move all codec formats to the o.a.l.codecs.Lucene90 package
> -----------------------------------------------------------
>
> Key: LUCENE-9705
> URL: https://issues.apache.org/jira/browse/LUCENE-9705
> Project: Lucene - Core
> Issue Type: Wish
> Reporter: Ignacio Vera
> Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Current formats are distributed in different packages, prefixed with the
> Lucene version they were created. With the upcoming release of Lucene 9.0, it
> would be nice to move all those formats to just the o.a.l.codecs.Lucene90
> package (and of course moving the current ones to the backwards-codecs).
> This issue would actually facilitate moving the directory API to little
> endian (LUCENE-9047) as the only codecs that would need to handle backwards
> compatibility will be the codecs in backwards codecs.
> In addition, it can help formalising the use of internal versions vs format
> versioning ( LUCENE-9616)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
