[
https://issues.apache.org/jira/browse/LUCENE-9616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17272507#comment-17272507
]
Julie Tibshirani commented on LUCENE-9616:
------------------------------------------
Would we be okay 'formalizing' this guideline going forward? Specifically, that
we should create new formats (and copy old ones to backwards-codecs) for
all-non-trivial changes. It'd be great to get feedback from [~jpountz] and
[~ivera] in particular, since you recently made several file format changes.
For context, I am working on some developer docs around updating file formats.
> Improve test coverage for internal format versions
> --------------------------------------------------
>
> Key: LUCENE-9616
> URL: https://issues.apache.org/jira/browse/LUCENE-9616
> Project: Lucene - Core
> Issue Type: Test
> Reporter: Julie Tibshirani
> Priority: Minor
>
> Some formats use an internal versioning system -- for example
> {{CompressingStoredFieldsFormat}} maintains older logic for reading an
> on-heap fields index. Because we always allow reading segments from the
> current + previous major version, some users still rely on the read-side
> logic of older internal versions.
> Although the older version logic is covered by
> {{TestBackwardsCompatibility}}, it looks like it's not exercised in unit
> tests. Older versions aren't "in rotation" when choosing a random codec for
> tests. They also don't have dedicated unit tests as we have for separate
> older formats, for example {{TestLucene60PointsFormat}}.
> It could be good to improve unit test coverage for the older versions, since
> they're in active use. A downside is that it's not straightforward to add
> unit tests, since we tend to just change/ delete the old write-side logic as
> we bump internal versions.
--
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
