[
https://issues.apache.org/jira/browse/SOLR-15845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17466187#comment-17466187
]
Jan Høydahl commented on SOLR-15845:
------------------------------------
Thanks for the feedback. I kept luceneMatchVersion around for anything that
smelled like Analysis or index binary back-compat stuff like index readers,
segment handler, index backup/restore etc. I know we have used Lucene's Version
class to decide some Solr feature behavior in the past, which would be wrong
now. If such need arises in the future, we'd perhaps need a
{{<solrMatchVersion>}} somewhere. But for now I'd like to just establish the
SolrVersion class and start using it where it is obviously the correct thing to
do. So far it's used by a few get-current-version prints and checking of Solr
Package version constraint.
I think perhaps the simpler version class in PR#472 is the way to go since we
don't have the same complex version needs as Lucene.
The proposal of deprecating {{<luceneMatchVersion>}} deserves its own Jira and
deeper analysis I believe.
> 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: main (9.0)
>
> Time Spent: 40m
> 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.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
