[ 
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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to