Backport MatchQuery into 6.x branch

[reedy]

Related to #1799 and #1793

While it's not so important that the 6.x branch supports PHP 8.0 (at least for us, for other people it might be), it'd be useful if MatchQuery in some form or another is backported into the 6.x branch, allowing code that needs to support 6.x | 7.x is able to set a version constraint to bring in the newer version of 6.x (ie 6.2 onwards or similar), and have the MatchQuery class available for both branches, to ease later migration burdens, and also not having to support both Match and MatchQuery in extends and use clauses etc.

In the simplest form, I guess a class_alias or class MatchQuery extends Match {} would do it. But for ease, it might be "easier" to backport all of #1799 to keep any subsequent backports and such easier (if they happen to touch the same code).

[ruflin]

++ on making the migration easier. I would prefer to have the change as lightweight as possible on the 6.x branch. I'm worried that we might break something by accident and then need to have more maintenance on the 6.x branch. So if the "extends" approach works this would be my preference, but happy to be convinced otherwise.

For the backports: I'm hopping we have very few / none of these to 6.x but I'm sure reality will proof me wrong.

[reedy]

I believe it should be enough. As long as it's in the same tree (so something like class MatchQuery extends Match {}), we all know PHP isn't overly strict on many things.

So that will allow people for migration to replace Match with MatchQuery (just needing to bump their 6.x requirement to effectively be >= the next 6.x release). Then when they switch to/allow 7 (and similarly, set >= the next 7.x release), this "migration" is done. Obviously other changes might be needed for other things, but that's fine.

As above, it's not so much for PHP 8.0 support via Elastica 6.x (though if that's possible, maybe it's beneficial; in that case MatchQuery extends Match might not actually work on PHP 8 as it wouldn't be valid syntax. The way you've done it in 7.x in theory should be fine as the Match extends MatchQuery shouldn't really be executed unless someone triggers the autoloading), it's more so that potentially both 6.x and 7.x can be supported without having to put conditionals on the class they need to use Match/MatchQuery

I guess in part, it all depends what https://github.com/elastic/elasticsearch-php end up doing in terms of PHP 8 support in their branches. https://github.com/elastic/elasticsearch-php#php-version-requirement says for 6.0 >= 7.0.0, and 7.0 >= 7.1.0; but >= isn't semver, so technically means PHP 8.0 for both. In composer.json, for 6.0 it's ^7.0 and 7.0 it's ^7.1. which obviously doesn't include PHP 8.0. I've filed elastic/elasticsearch-php#1083 for the table clarifying.

I think we should be able to publish a new 7.1.0 version in the coming days, but it would be better to wait for the elasticsearch official library to be officially compatible with PHP 8.0 before publishing the 7.1.0.

I've also just filed elastic/elasticsearch-php#1084 asking for which version(s) are going to support PHP 8.0, to help answer #1799 (comment)

[reedy]

PR up... :)

[reedy]

If we can get a release after that PR is merged, that'd be appreciated!

Changes on the 6.x branch: 6.1.1...6.x

[deguif]

It was merged.

[reedy]

Thanks!

Should I file a seperate task about a new 6.x release? 6.1.2, presumably? 6.1.1...6.x

[reedy]

Oh, duh. Just saw #1901

👍

[deguif]

Version 6.1.2 was just released.