update updating.md

[maryamsulemani97]

closes #1849 and #1583

• This is a three-step guide with sub-headings for the other steps
• Added a heading on "version-specific instructions" at the beginning of the guide
• Used bold for cloud platforms to help it stand out
• For this version of the guide, old versions will only have curl code samples

---

• Update code samples to use X-Meili-API-Key: API_KEY for v0.24 and below
• Update the "Set all fields as displayed attributes" step to
  • use updateId instead of taskUid
  • use processed instead of succeeded
• Use {} for dumpfile in the "create dump" step
• Update note to mention v1
• add content for updating Meilisearch on cloud platforms
  • add tabs for local installation and cloud platforms for code samples
  • update code samples to use <your-domain-name> instead of local host

[dichotommy]

Hey, thanks for your work on this. It's getting there, and I think combining the two guides was a good idea. Hopefully we can continue working on this and cleaning it up as we head towards v1 🚀

[dichotommy]

My broad response to this guide is that it's looking very good. The main thing that I'd like to continue to work on is streamlining the steps.

Having lots of version-specific notes and warnings can really break up the flow of the guide and make the process feel a lot more complicated than it actually is.

(Really, it's pretty simple! But with all the text boxes and code samples and steps, it looks complicated. And if it looks complicated, then it feels complicated. We don't want that.)

Obviously, with such a wide range of Meilisearch versions from which the user might be migrating, we cannot possibly document everything that might differ from our provided process / code samples.

For example, if we note every time we show a task that tasks were added in v0.25 and the process was different before, I think it will be a very long guide (actually, we may be doing this already 👀 ).

My response to this would be to try to centralize these warnings as much as possible, with the goal of making the upgrade steps themselves as clean and easy to follow as possible. Perhaps these version-specific warnings could even go in a dedicated section.

Of course some warnings are context-sensitive and need to appear next to a specific code sample or instruction. Still, I think we can do a lot more to improve the guide in this area 💪🏻 🛠️

On a related subject, I also think that we should consider our options for reducing the number of steps. A 9-step process is always going to feel like a pain, even if the individual steps are quick and easy. I would recommend combining steps where possible, especially by utilizing more H3s within the guide (or rather, ANY H3s, since right now it's entirely H2s). Combining steps often means making step titles more thematic (e.g. "Prepare for migration" to encompass steps 4, 5, and 6), rather than specific and detailed.

@maryamsulemani97 Shoot me a message if you want to run any ideas by me or if you have questions or concerns about anything I've said.

[dichotommy]

Wow. In my opinion, this is a massive improvement over the previous version of the guide. I suggested it, but even I wasn't expecting you to be able to condense the guide this much. 👏🏻 🧱

For the version-specific update instructions section, I think long term it will make sense to use headers (corresponding to the affected versions) or a table for these. But for now bullet points seems fine!

[dichotommy]

LGTM 🌊🏄🏻😎

[maryamsulemani97]

bors merge

[bors]

Build succeeded:

• check-builds (14)
• check-builds (16)
• check-links
• check-style
• vale