meilisearch/documentation/release.md

Meilisearch release process

This guide is to describe how to make releases for the current repository.

📅 Weekly Meilisearch release

1. A weekly meeting is held every Thursday afternoon to define the release and to ensure minimal checks before the release.

Check out the TODO 👇👇👇

- [ ] Define the version of the release (`vX.Y.Z`) based on our Versioning Policy
. - [ ] Define the commit that will reference the tag release. Every PR merged after this commit will not be taken into account in the future release - [ ] Manually test `--experimental-dumpless-upgrade` on a DB of the previous Meilisearch minor version
- [ ] Check recent automated tests on `main`
- [ ] Scheduled test suite
- [ ] Scheduled SDK tests
- [ ] Scheduled flaky tests
- [ ] Scheduled fuzzer tests
- [ ] Scheduled Docker CI (dry run)
- [ ] Scheduled GitHub binary release (dry run)
- [ ] Create the PR updating the versionand merge it.

2. Go to the GitHub interface, in the Release section.

3. Select the already drafted release or click on the Draft a new release button if you want to start a blank one, and fill the form with the appropriate information. ⚠️ Publish on a specific commit defined by the team. Or publish on main, but ensure you do want all the PRs merged in your release.

⚙️ The CIs will be triggered to:

• Upload binaries to the associated GitHub release.
• Publish the Docker images (latest, vX, vX.Y and vX.Y.Z) to DockerHub -> check the "Docker meta" steps in the CI to check the right tags are created
• Publish binaries for Homebrew and APT
• Move the latest git tag to the release commit.

🔥 How to do a patch release for a hotfix

It happens some releases come with impactful bugs in production (e.g. indexation or search issues): we obviously don't wait for the next cycle to fix them and we release a patched version of Meilisearch.

1. Create a new release branch starting from the latest stable Meilisearch release (latest git tag or the corresponding vX.Y.Z tag).

# Ensure you get all the current tags of the repository
git fetch origin --tags --force

# Create the branch
git checkout vX.Y.Z # The latest release you want to patch
git checkout -b release-vX.Y.Z+1 # Increase the Z here
git push -u origin release-vX.Y.Z+1

2. Add the newly created branch release-vX.Y.Z+1 to "Target Branches" of this GitHub Ruleset. Why? GitHub Merge Queue does not work with branch patterns yet, so we have to add the new created branch to the GitHub Ruleset to be able to use GitHub Merge Queue.

3. Change the version in Cargo.toml file. You can use our automation -> click on Run workflow -> Fill the appropriate version and run it on the newly created branch release-vX.Y.Z -> Click on "Run workflow". A PR updating the version in the Cargo.toml and Cargo.lock files will be created.

4. Open and merge the PRs (fixing your bugs): they should point to release-vX.Y.Z+1 branch.

5. Go to the GitHub interface, in the Release section and click on Draft a new release ⚠️⚠️⚠️ Publish on release-vX.Y.Z+1 branch, not on main!

⚠️ If doing a patch release that should NOT be the latest release:

• Do NOT check Set as the latest release when creating the GitHub release. If you did, quickly interrupt all CIs and delete the GitHub release!
• Once the release is created, you don't have to care about Homebrew, APT and Docker CIs: they will not consider this new release as the latest; the CIs are already adapted for this situation.
• However, the CI updating the latest git tag is not working for this situation currently and will attach the latest git tag to the just-created release, which is something we don't want! If you don't succeed in stopping the CI on time, don't worry, you just have to re-run the old CI corresponding to the real latest release, and the latest git tag will be attached back to the right commit.

6. Bring the new commits back from release-vX.Y.Z+1 to main by merging a PR originating release-vX.Y.Z+1 and pointing to main.

⚠️ If you encounter any merge conflicts, please do NOT fix the git conflicts directly on the release-vX.Y.Z branch. It would bring the changes present in main into release-vX.Y.Z, which would break a potential future patched release.

Instead:

• Create a new branch originating release-vX.Y.Z+1, like tmp-release-vX.Y.Z+1
• Create a PR from the tmp-release-vX.Y.Z+1 branch and pointing to main
• Fix the git conflicts on this new branch
  • By either fixing the git conflict via the GitHub interface
  • By pulling the main branch into tmp-release-vX.Y.Z+1 and fixing them on your machine.
• Merge this new PR into main