Come up with a strategy for the name attribute for the config element

the drupal-* seems the more generic solution here, but I would happily settle for anything else. As long as the name reflects the version of solr it is ok.

We can switch to "drupal-*", no problem. Even less so if we manage a completely unified solrconfig.xml file.
Otherwise, we could do things like "drupal-1.2-apachesolr-1.1" to distinguish the base unified file from our customizations. "drupal-1.2" would be the generic file on which the config is based, "apachesolr-1.1" would mean that this is the second modification of that base file by the apachesolr module.

Agreed. Would we add the solr version 1.4.x / 3.x in the name to make it super clear and eventueel even have a check in the module to see if the schema is correct?

What if we make the name configurable in solrcore.properties?

<config name="drupal-1.2-${drupal.module:apachesolr}-${drupal.version:7.x-1.x}">

What if we make the name configurable in solrcore.properties?

I don't think that would make much sense. Making the version of the file configurable by whoever uses it is contrary to the purpose of having a version.

Adding the Solr version is definitely a good idea, though.

Sooo … solr-3.x-drupal-1.2[-apachesolr-1.1] (the part in brackets only if the common file was modified in apachesolr)?
Or does this look too much like "1.2" is the Drupal version? But I guess leaving "drupal" out would make it harder to spot whether you're using the right configs.

we can have two variables

<schema name="solr-3.x-drupal-7" version="1.0-apachesolr-0.1">
<schema name="solr-3.x-drupal-7" version="1.0-searchapi-0.2">

This would remove all confusions and address all flexibility issues. the name = base schema, version = module specific things. In the best case, we do not have module specific cases anymore.

<schema name="solr-3.x-drupal-7" version="1.0">

This is what we are pursuing, so my opinion is that we do not even allow a search specific module. The schema/configs are flexible enough to allow this for both.

From the default schema.xml:

<!-- attribute "name" is the name of this schema and is only used for display purposes.
	version="x.y" is Solr's version number for the schema syntax and semantics. It should
	not normally be changed by applications.
	1.0: multiValued attribute did not exist, all fields are multiValued by nature
	1.1: multiValued attribute introduced, false by default
	1.2: omitTermFreqAndPositions attribute introduced, true by default except for text fields.
	1.3: removed optional field compress feature
	1.4: default auto-phrase (QueryParser feature) to off
	1.5: omitNorms defaults to true for primitive field types (int, float, boolean, string...)
	-->

So, it doesn't seem like we can (or should) do that. Might even lead to an exception at startup and complete shutdown.
Also, solrconfig.xml doesn't even have a version attribute, so we couldn't use that approach for both, anyways.

Having the Drupal version in there is a good idea, in any case. So solr-3.x-drupal7-1.2[-apachesolr-1.1] maybe?

Fixed after discussion in drupalcon, see

in the repo

in IRC we settled for

since drupal-1, drupal-2 and drupal-3 are already in use. 4.0 makes sense to show this is the next big change.

There was some discussion about the lucenematchversion and wether or not this should be in the naming convention - we can always come back to that if required.

committed this new name