[ 
https://issues.apache.org/jira/browse/SOLR-12420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17343079#comment-17343079
 ] 

Jan Høydahl commented on SOLR-12420:
------------------------------------

The luceneMatchVersion is not the same as Lucene version. It is a config option 
in solrconfig that is used both to ensure consistent behaviour of analysis 
components, but also a few other places in Solr code to make a breaking change 
depend on user's luceneMatchVersion.

Now that we'll get a new independent SolrVersion class we also must consider 
this. Will this be a configurable solrMatchVersion, that users can configure to 
guard against various breaking changes, like we have used luceneMatchVersion? 
Or will SolrVersion be locked to the actual Solr version running?

One way to handle the schema could be to ship the examples without a version 
attribute (defaulting to latest), but still support the attribute for when 
there is a need to lock it.

> Propose removing schema version; use luceneMatchVersion instead
> ---------------------------------------------------------------
>
>                 Key: SOLR-12420
>                 URL: https://issues.apache.org/jira/browse/SOLR-12420
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: David Smiley
>            Assignee: David Smiley
>            Priority: Major
>             Fix For: main (9.0)
>
>
> I propose that the schema version be removed in lieu of using 
> luceneMatchVersion for this.  One less thing to manage (in code, need REST 
> API -- SOLR-7242, thing to document; etc.).  We don't need the fidelity to 
> differentiate from luceneMatchVersion.  We're already using 
> luceneMatchVersion for things instead of having a ton of additional version 
> numbers.  I can understand the point of putting a version number in in a 
> config file but I don't think we should continue this practice.
> To make this happen, if the luceneMatchVersion is >= 7.4 (the release which 
> we start doing this) then a non-existent schema version becomes equivalent to 
> the latest schema version.  Specifying the schema version becomes deprecated 
> but supported; we might log a warning. 
> In 8.0, strip schema version out altogether.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to