integration-guides: Avoid mismatch between Meilisearch server and the SDK

Context: Today, when a user updates its SDK and uses a new method, suppose multiSearch, it also should update the Meilisearch server running to the latest version. Otherwise, they will face an error. This situation is terrible for the user because they will see that probably only in production, bringing a lot of headaches, hours of debugging, and more.

So, knowing that I suggest to the @meilisearch/integration-team think and propose an active solution to solve that issue. Alerts, documentation anything that can help are welcome. A solution proposal was made here, in the rails repository and could be a starting point for the discussion.

TODO:

  • Showcase examples on the web for this problem.
  • Find a solution to all the tier #1 and tier #2 SDKs.
  • Implement it accordingly in each
  • Change the release changelog disclaimer to the suggestion below.

@meilisearch/integration-team, we should change our release disclaimer to this:


This version introduces features released on Meilisearch v1.1.0 🎉 Check out the changelog of Meilisearch v1.1.0 for more information on the changes. If you want to adopt new features of this release, update the Meilisearch server to the according version.


So this way, we state clearly to the users that if they have plans to adopt the new features, they MUST update the Meilisearch server as well, so we can at least try to avoid situations like this:

And the list goes on. There are a lot of examples, and they will still happen even after Meilisearch v1.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 1
  • Comments: 15 (6 by maintainers)

Most upvoted comments

I don’t disagree. It’s just that it’s not currently possible.

The issue with that is when the API key provided does not have the right to call /version. On search keys or custom keys for example.

I didn’t think about this. This means the client is going to have to 100% manage all of this itself and maintain differences between package versions at runtime. This is going to be really hard to keep up with.

The challenge there is going to be Meilisearch is going to return a generic error because by definition of the problem the server won’t know what you are trying to do. Only the client could possibly know the issue so my only thought right now (and I don’t think it is a good one) is the client could request the server version and use that to throw an error if something is used that isn’t implemented in the server version.

I think with it in the README it won’t solve the problem. I highly doubt people are reading the full readme before using the client, especially if it is an update to the client. Unfortunately I don’t have a suggestion for a better solution though.