Only track released versions in oldVersions.

[jpountz]

This would avoid test failures when a release is in progress.

[jpountz]

More fixes are needed, I'm looking.

[jpountz]

We used to have logic to allow up to one missing file to account for in-progress releases: https://github.com/apache/lucene/blob/releases/lucene/9.8.0/lucene/backward-codecs/src/test/org/apache/lucene/backward_index/TestBackwardsCompatibility.java#L805-L843. We need to figure out a way to replicate this logic with the new parameterized testing.

It would help if we could have access to an authoritative list of released versions, e.g. via the DOAP file maybe?

[uschindler]

We used to have logic to allow up to one missing file to account for in-progress releases: https://github.com/apache/lucene/blob/releases/lucene/9.8.0/lucene/backward-codecs/src/test/org/apache/lucene/backward_index/TestBackwardsCompatibility.java#L805-L843. We need to figure out a way to replicate this logic with the new parameterized testing.

Hahaha that logic is crazy....

It would help if we could have access to an authoritative list of released versions, e.g. via the DOAP file maybe?

This could work, but that would require network access at test time which is not allowed (security manager). Replicating the DOAP file to the repo seems like it defeats its purpose.

I tend to replicate the previous logic.

[uschindler]

See this issue for more insights to the "crazy logic": https://issues.apache.org/jira/browse/LUCENE-5936

[uschindler]

@RmuirSays: "yes please, lets not do the network. the smoketester can do that. In fact mike already wrote the code."

[jpountz]

@uschindler I also have a bias against adding more dependencies on network resources, this is why I was thinking of the DOAP files since we have them in the repository: https://github.com/apache/lucene/blob/main/dev-tools/doap/lucene.rdf.

[uschindler]

@uschindler I also have a bias against adding more dependencies on network resources, this is why I was thinking of the DOAP files since we have them in the repository: https://github.com/apache/lucene/blob/main/dev-tools/doap/lucene.rdf.

Oh that's new to me. Cool idea. Parsing with a simple stax parser should work. Unfortunately those are outside of test resources and can't be loaded easily.

I am tempted to add the legacy behaviour back. It's proven to work since 10 years. The code wasn't changed since that old issue.

[uschindler]

P.S.: Unrelated to this issue here: we should update the doap file to use https links (not for the namespaces and controlled vocabularies, but those to our project homepage).

See #13097

[jpountz]

I pushed a new commit that revives the old logic that allowed up to one version missing backward-compatibility data.

[uschindler]

Thanks. We may look into better solutions at a later stage. For now this is perfect and stops builds from failing.

[uschindler]

With our last change, we may need to change the script that adds the backwards indexes. Or is this now how it worked before?

[jpountz]

@uschindler I'm not sure to understand what you mean. The script that adds bw compat indices indeed needs updating to update the oldVersions array when introducing bw compat indices for a new release.

[jpountz]

(which is what Simon is doing at #13095)

[uschindler]

Thanks!