Dgraph Release Process

This document outlines the steps needed to build and push a new release of Dgraph.

Have a team member "at-the-ready" with github writer access (you'll need them to approve PRs).
Create a new branch (prepare-for-release-vXX.X.X, for instance).
Update dependencies in go.mod for Badger, Ristretto and Dgo, if required.
If you didn't update go.mod, decide if you need to run the weekly upgrade CI workflow, ci-dgraph-weekly-upgrade-tests, it takes about 60-70 minutes… Note that you only need to do this if there are changes on the main branch after the last run (it runs weekly on Sunday nights).
Update the CHANGELOG.md. GenAI does a great job of doing this. Example prompt: I'm releasing vXX.X.X off the main branch, add a new entry for this release. Conform to the "Keep a Changelog" format, use past entries as a formatting guide. Run the trunk linter on your changes..
Validate the version does not have storage incompatibilities with the previous version. If so, add a warning to the CHANGELOG.md that export/import of data will need to be run as part of the upgrade process.
Commit and push your changes. Create a PR and have a team member approve it. If you've only modified markdown content, the code-based CI steps will be skipped.
Using the updated CHANGELOG.md as a guide, ensure that user-facing additions or changes have appropriate PRs in the Dgraph docs repo.
Once your "prepare for release branch" is merged into main, on the github releases page, create a new draft release (this step will create the tag, in this example we're releasing v25.1.0-preview1):

Note: check the toggle to create a Annoucement in our Discussions forum (time saver).
Start the deployment workflow from here:

Note: only select the "if checked, images will be pushed to dgraph-custom" if this release is an unreleased patch.

The CD workflow handles the building, tagging and copying of release artifacts to dockerhub and the releases area.
Verify the push
1. Ensure the image tags are pushed to https://hub.docker.com/r/dgraph/dgraph/tags
2. Run these commands to verify the version:
```
docker run --pull always dgraph/dgraph:vXX.X.X dgraph version
docker run --pull always dgraph/dgraph:latest dgraph version
docker run --pull always dgraph/standalone:latest dgraph version
```
3. The new CD workflow should copy all artifacts to the release (there should be 10 artifacts with the release). If not, at the end of the CD workflow, you'll find the created artifacts that you'll need to download and then re-upload to the release, sigh... (click on the 'edit' button of the release--use artifact names from prior release as a guide)
For all releases (non-previews and non-patches), create a release branch. In order to easily backport fixes to the release branch, create a release branch from the tag head. For instance, if we're releasing v25.1.0, create a branch called release/v25.1 from the tag head (ensure you're on the main branch from which you created the tag)
sh
```
git checkout main
git pull origin main
git checkout -b release/v25.1
git push origin release/v25.1
```
Check the Discussions forum for the announcement of the release (create one if you forgot that step above which autocreates one).
If the release has documentation changes, alert the docs team to merge the doc changes in the dgraph-docs repo.