[
https://issues.apache.org/jira/browse/SOLR-15845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18099786#comment-18099786
]
Jan Høydahl commented on SOLR-15845:
------------------------------------
We only use the SolrVersion class in this issue to parse and compare versions,
and bump the {{LATEST}} constant. We do not use it for back compatibility
checks.
In reality it is the Lucene layer that tend to break compatibility, not solr
version. So luceneMatchVersion can guard a user against changed lucene behavior
between versions, if they pin lucene version in solrconfig.
Can you point to a use case where we'd like to gate some logic on solr version
instead? If so, in what config file would we record the "solrMatchVersion"?
Right now we tend to NOT do breaking changes in minor versions, thus we should
not need such a config unless we plan to allow more breaking changes in minor
versions, e.g. different defaults for schema or certain configs?
> Solr needs its own Version class
> --------------------------------
>
> Key: SOLR-15845
> URL: https://issues.apache.org/jira/browse/SOLR-15845
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 9.0
> Reporter: Jan Høydahl
> Assignee: Jan Høydahl
> Priority: Blocker
> Fix For: 9.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> From 9.0 on, Solr may release with a different version number than the Lucene
> it depends on, since Lucene is just another jar dependency now.
> Several places in our code base we either print a version based on Lucene
> Version, or make other decisions based on it. It's still the correct Version
> to use for index compatibility and analysis plugins, but other places we need
> a {{SolrVersion}} to replace it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
