snowykami/meilisearch
1
0
Fork 0
mirror of https://github.com/meilisearch/meilisearch.git synced 2025-09-05 12:16:32 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update documentation

Browse Source
This commit is contained in:
curquiza
2025-07-20 22:07:23 +02:00
parent 421a23ee3d
commit c2c82be556
6 changed files with 344 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

75
documentation/release.md Normal file
View File

@ -0,0 +1,75 @@
# Meilisearch release process
This guide is to describe how to make releases for the current repository.
## 📅 Weekly Meilisearch release
1. A weekly meeting is done every Monday to define the release and check the following information
<details>
<summary>👇👇👇</summary>
- [ ] Define the version of the release (`vX.Y.Z`)
- [ ] Manually test `--experimental-dumpless-upgrade` on a DB of the previous Meilisearch minor version</br>
- [ ] Check recent <a href="https://github.com/meilisearch/meilisearch/actions">automated tests</a> on `main`</br>
- [ ] Scheduled test suite</br>
- [ ] Scheduled SDK tests</br>
- [ ] Scheduled flaky tests</br>
- [ ] Scheduled fuzzer tests</br>
- [ ] Scheduled Docker CI (dry run)</br>
- [ ] Scheduled GitHub binary release (dry run)</br>
- [ ] <a href="https://github.com/meilisearch/meilisearch/actions/workflows/update-cargo-toml-version.yml">Create the PR updating the version</a>and merge it.
</details>
1. Go to the GitHub interface, in the [`Release` section](https://github.com/meilisearch/meilisearch/releases).
2. 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 `main`
⚙️ The CIs will be triggered to:
- [Upload binaries](https://github.com/meilisearch/meilisearch/actions/workflows/publish-binaries.yml) to the associated GitHub release.
- [Publish the Docker images](https://github.com/meilisearch/meilisearch/actions/workflows/publish-docker-images.yml) (`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](https://github.com/meilisearch/meilisearch/actions/workflows/publish-apt-brew-pkg.yml)
- [Move the `latest` git tag to the release commit](https://github.com/meilisearch/meilisearch/actions/workflows/latest-git-tag.yml).
### 🔥 How to do a patch release for an 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).
```bash
# 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. Change the [version in `Cargo.toml` file](https://github.com/meilisearch/meilisearch/blob/e9b62aacb38f2c7a777adfda55293d407e0d6254/Cargo.toml#L21). You can use [our automation](https://github.com/meilisearch/meilisearch/actions/workflows/update-cargo-toml-version.yml) -> 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.
3. Open and merge the PRs (fixing your bugs): they should point to `release-vX.Y.Z+1` branch.
4. Go to the GitHub interface, in the [`Release` section](https://github.com/meilisearch/meilisearch/releases) and click on `Draft a new release`
⚠️⚠️⚠️ Publish on `release-vX.Y.Z+1` branch, not on `main`!
⚠️ <ins>If doing a patch release that should NOT be the `latest` release</s>:
- 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](https://github.com/meilisearch/meilisearch/actions/workflows/latest-git-tag.yml) 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](https://github.com/meilisearch/meilisearch/actions/workflows/latest-git-tag.yml) corresponding to the real latest release, and the `latest` git tag will be attached back to the right commit.
5. 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.
![GitHub interface showing merge conflicts](../assets/merge-conflicts.png)
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`