About the 8.0 version

[deguif]

Here's what I would like to propose:

• Create a new branch 7.x (branched from master)
• Create a new branch 8.x

For the 8.x branch, I propose to bump PHP version to 8.0 so that we can start using some recent PHP language evolutions (union type, named arguments, ...).

[ruflin]

I would make small adjustment to the proposal. Created a 7.x branch but no 8.x branch. 8.x is just master. Like this we need to do less backports.

[deguif]

@ruflin I can create the 8.x branch, but I'm afraid I can't rename the master branch to 7.x as I don't see the edit button on it?

[ruflin]

Seems like I have this edit button. But as master is the default branch I rather rename it to 8.x and the branch 7.x from it. Does this also make sense?

[thePanz]

I would rename it to 7.x, as the current PRs are for the 7.x releases
As the 8.x branch just started, it is Ok (IMHO) to have it as a new branch.. wdyt?

[deguif]

👍 with @thePanz
I was thinking the same ;)

Or rename master to 7.x, and branch 8.x from 7.x as current open PRs target 7.x version

[ruflin]

The problem I have with this is that now we have to start forward port PRs. If we forget one, we have it in 7.x but no 8.x. Only 8.x is fine, only 7.x but not 8.x seems like an issue.

As the current PR's target master my thinking is these target 8.x. If we fork off 7.x from it, it will be in 7.x too.

[thePanz]

Should we define a list of "goals" for the new 8.0 version?
Maybe having a set of issues grouped into a milestone? WDYT?

My short list:

• More strict methods signatures (getting rid of arguments with "string|int|array|Class|null" as type)
• throwing exceptions when a call to ES failed (in some cases we return the Response, which contains errors)
• more?

[ruflin]

• Removal of deprecated code

We can use a milestone or just a meta github issue. Both works for me.

[damienalexandre]

As far as the wishlist goes:

• Clarify the usage / need of elasticsearch/elasticsearch: Elastica ship a Client, elasticsearch/elasticsearch too, and version 8 is even installing HttpPlug. There is also differences in the logging methods. Removing elasticsearch/elasticsearch could be nice IMO because I don't see why it's required by Elastica;

About the PHP requirement, I'm for keeping a maximum of compatibility, so 7.4 as minimum for now.

[ruflin]

@damienalexandre I added elasticsearch/elasticsearch as a dependency quite some time ago. The idea was to have it as an escape hatch if something is not supported by Elastica directly.

[coreation]

hey @ruflin just got see this 8.0 thread, does this mean if someone wants to use an 8.2 ElasticSearch feature, and there is compat. issue between Elastica 8.0 and ElasticSearch 8.2, we can just use the underlying dependency (elasticsearch/elasticsearch) to use that 8.2 feature?

[ruflin]

Potentially. The devil is always in the detail but likely yes. What you can always do is send "raw" json queries with Elastica.

[deguif]

• properties type-hinting
• get rid of custom encode/decode json handling (now that JSON_THROW_ON_ERROR will be available)
• mark some classes as final (to simplify BC)
• review properties/method naming (removing _ prefix for example)

About the version of PHP, I would require 8.0 as minimum version as 7.4 is in security support only maintenace mode. Many libraries already switched to 8.0 as minimum version. In the meantime we could maintain more regurlaly the 7.x branch for the ones that would be sticked to PHP 7.4 version or previous.

Advantage brought by PHP 8.0 would be for this library:

• union type
• static return type-hint (to avoid @return this annotation)
• named arguments (json_decode for example , it would avoid having to specify $depth when specifying custom flags)
• mixed type-hint
• Stringable interface
• ...

[ruflin]

Only supporting PHP 8.0 means that only users of PHP 8.0 can migrate to Elasticsearch 8.0. It is possible that Elastica 7.x will mostly work with Elasticsearch 8.0 but it is not guaranteed as there can be breaking changes.

One other data point is likely on what @ezimuel does with the official client on PHP version compatiblity?

[ezimuel]

We really would like to use the new features of PHP 8 for elasticsearch-php 8.0 but we still need to support PHP 7.4 until 28 Nov 2022. We have many users using PHP 7.4
That said, elasticsearch-php8.0.0 will still support PHP 7.4+. Btw, the named argument will be supported anymore since it's about how to call a function rather than how to write it. Moreover, we will finally use the class property type definition used by PHP 7.4.

[damienalexandre]

About Elasticsearch 8.0 compatibility, there is a new compatibility layer in Elasticsearch we could leverage while working on the next Elastica version: https://www.elastic.co/guide/en/elasticsearch/reference/8.0/rest-api-compatibility.html

By adding:

Accept: "application/vnd.elasticsearch+json;compatible-with=7"
Content-Type: "application/vnd.elasticsearch+json;compatible-with=7"

to all requests, the version 7 of Elastica could work with Elasticsearch 7 and 8.

[damienalexandre]

• It does not break anything if always there.
• The official client has an environment variable to enable it: Add support for API Compatibility Header elastic/elasticsearch-php#1142

Both ways looks good to me.

[ruflin]

I like the idea of the environment variable and also it is in line with the official client.

[ezimuel]

@ruflin actually I need to add the API Compatibility header in elasticsearch-php v8. I rewrote the client from scratch supporting PSR-7 and PSR-8 standards and I need to re-apply some pieces. I opened this PR elastic/elasticsearch-php#1221 for taking care of this.

[ruflin]

@ezimuel Why do you still need the header in 8? Is 8 compatible with 7?

[ezimuel]

@ruflin I think this is because we need to keep track of the version when we will release Elasticsearch 9.

[AndreasA]

Just wondering if there has been any news regarding 8.x support?

Also if you add compatibility support using enviornment variables, plase use $_SERVER and $_ENV instead of getenv to support symfony/dotenv and be thread-safe.

[ruflin]

Thanks for the ping @AndreasA We should start to make a move on the 8.x support. I was out for a few weeks so I'll ping @deguif @thePanz to see if any changes happened during that time also around branching?

[sidz]

@ruflin do you need any help? I open to invest some time into this package and help to move forward to ES 8

[ruflin]

@sidz Thanks for your offer, it would be great if could help out here. In this thread there were quite a few discussions, some with conclusions, some with open questions. Ideally we close this conversations and come to a conclusion to drive finally get 8.0 out of the door. Could you help with that?

[sidz]

Hey @ruflin.
Based on conversation #1961 here are simple steps which need to be done before we move forward and start to do something.

0. Release new 7.3? version in case there is smth to release
1. Rename master to 7.x
2. Create 8.x from 7.x
3. Delete master branch

after that:

1. Drop support for php <8.0 (7.4 is end of life)
2. Update official elasticsearch lib and add compatibility layer for 7.4 (Also here: improve CI pipeline and run library against ES 8)
3. Moving forward :)

[ruflin]

7.17.x is supported until "The later of 2023-08-01 or the release date of 9.0.0". As there is no 9.0 out yet, 7.17.x will stay supported is my understand.

@mussbach To your question, I strongly hope we make some quick progress on moving to 8.0 but at the same time it is quite a bit of effort. Can't give you an estimate.

[mussbach]

Sorry to constantly come back to this. Any news on the update to elasticsearch 8? Alternatively: Do you know any other lib that supports elasticsearch 8 for php?

[ruflin]

We are close on getting the major change to 8.x in: #2181 @mussbach Would you be willing to help testing / trying it out? Otherwise, there is the official elasticsearch php client which should work with 8.x.

[mussbach]

Nice, this is good news! I can definitely test and probably help to fix some bugs, if there are some suitable ones.

[ruflin]

@mussbach Great to hear. Please subscribe to the PR so you stay up-to-date.

[ruflin]

A major pull request to get us to version 8 compatibility has just been merged: #2181 Please help with testing, reporting bugs and bug fixes. Still a bit of work ahead of us tracked in #2185

[ruflin]

Release 8.0.0 is out: https://github.com/ruflin/Elastica/releases/tag/8.0.0 Going to close this thread. Thanks for everyone that helped us to get here. Next step is upgrading projects / libs and get all the feedback in.