Solarium 6.1 and 7.0

[mkalkbrenner]

@wickedOne @thomascorthals @dmaicher

In some of the current PRs I noticed changes we should release as new minor or major versions. I think it males sense to quickly discuss and arrange them here.

[wickedOne]

the php 7.3 requirement should at least be a minor, but i would agree to a major as well as it's not entirely clear to me what the "best practice" is in this usecase.

changes to the helper class regarding date processing should be a major, but i can add an alias for the formatDate method with a deprecation message which would make it a minor; any preference on this?

[thomascorthals]

solarium/README.md

Line 13 in 7cf99c9

Solarium 6.x only supports PHP 7.2 and up.

Strictly speaking, this makes the PHP 7.3 requirement incompatible with a minor version because 6.1.0 is still 6.x.

[dmaicher]

Generally bumping the min php version can be done in a minor I think. Its not a BC break.

But seeing that we state this: Solarium 6.x only supports PHP 7.2 and up. maybe we need a major then...

We should probably first create a new branch 6.x then from current master and treat master as 7.x? Then we could collect some more changes with BC breaks until we release 7.0? And we can deprecate + release some things on 6.x so people can prepare for possible breaking changes in 7.0.

[thomascorthals]

According to the SemVer FAQ, it shouldn't be a major:

What should I do if I update my own dependencies without changing the public API?

That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. I would usually expect additional code for the latter instance, in which case it’s obviously a minor level increment.

We should be more specific in the docs. Since Solarium x.y.z, the minimal required PHP version is 7.3 (with x.y.z 6.1.0 or 7.0.0 depending on the outcome of this discussion). Maybe even a list with the minimal PHP version for every minor Solarium release? Could be convenient for users who are stuck on older PHP versions to find the newest release that would still work for them.

Personally, I would never bump the PHP requirement on a patch version, even though SemVer apparently allows it. And I wonder how many PHP projects "explicitly depend" on PHP 7.2 versus "run in an environment" that's still PHP 7.2 because of legacy components.

[wickedOne]

maybe we could be more abstract in our documentation by saying something like:

the latest version of solarium will be compattible with all maintained php versions at the time of the release

a reference table would be a nice addition indeed

[wickedOne]

i've been thinking about this one a bit and though i learned a hard lesson in my previous job by not keeping up to date (and therefor do it at the moment), i'm fully aware that there are plenty companies which are not able to upgrade for a variety of reasons.

i would not go as far as wordpress recently did, but perhaps we should reach a consensus on what strategy we'd like to have and maybe use polyfills to guarantee no bc breks?

[mkalkbrenner]

@thomascorthals @wickedOne @dmaicher
Just for completeness: For Solarium 6.1 we droped PHP 7.2 support and raised the minimum requirement to 7.3 :-)

Now to something else. The Solr project deprecated managed resources. As replacement they now offer an API to modify any file of a config-set. That's great!

I think we should do the same: Deprecate managed resources in 6.1 and remove the support in 7.0. And for sure we should add support for the new API, ideally v2 only.

[thomascorthals]

I caught that too. A bit of a bummer after all the work I've put in for #850. 😉

Should we go ahead and merge it anyway (after thorough review), then deprecate it? Old Solr versions tend to stick around in production environments. There's also a few things in there that are useful in general:

• A bugfix for HEAD requests with the cURL adapter.
• A proposed solution for API calls that return a 4xx response.
• Parsing statusMessage from a response.

[mkalkbrenner]

I'm fine with merging it. And you're right that we should support older Solr versions as long as they didn't reach EOL.
The immediate deprecation was an altertative to approach to fixing all that stuff ;-)
If the quality has been improved now, that's the better solution.

[thomascorthals]

Did we have an official source for the deprecation of managed resources? I don't remember where I read it.

The ref guide for 9.0 describes it as a staple of programmatical management, placing it on an equal footing with the Schema API. Nothing in the wording of that page suggests it'll be deprecated anytime soon.

Managed resources complement other programmatically manageable components in Solr, such as the RESTful schema API to add fields to a managed schema.

In fact, they even encourage users to use the same internal hooks in custom plugins.

Users can also write their own custom plugins, that leverage the same internal hooks to make additional resources REST managed.

[thomascorthals]

@mkalkbrenner Before we release Solarium 7.0, I'm going to commit a cleanup of deprecated functions that were going to be deleted for Solarium 6 and 7. Doesn't seem to have happened for 6.

[thomascorthals]

@mkalkbrenner I have a commit with cleanup of deprecations ready in my fork: thomascorthals@c67747e

Couldn't PR is yet because of merge conflicts. Just a heads up so you don't have to do duplicate work. ;-)