chore(docs): document release process (#9543)

**Description**

This PR adds a release process guide

Author: matthewmcneely

.github/CODEOWNERS

@@ -1,4 +1,4 @@
 # CODEOWNERS info: https://help.github.com/en/articles/about-code-owners
 # Owners are automatically requested for review for PRs that changes code
 # that they own.
-* @dgraph-io/database
+* @dgraph-io/maintainers

.github/PULL_REQUEST_TEMPLATE.md

@@ -4,17 +4,25 @@ Please explain the changes you made here.
 
 **Checklist**
 
-- [ ] Code compiles correctly and linting passes locally
-- [ ] For all _code_ changes, an entry added to the `CHANGELOG.md` file describing and linking to
-      this PR
+- [ ] The PR title follows the
+      [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/#summary) syntax, leading
+      with `fix:`, `feat:`, `chore:`, `ci:`, etc.
+- [ ] Code compiles correctly and linting (via trunk) passes locally
 - [ ] Tests added for new functionality, or regression tests for bug fixes added as applicable
-- [ ] For public APIs, new features, etc., PR on [docs repo](https://github.com/dgraph-io/docs)
-      staged and linked here
+- [ ] For public APIs, new features, etc., a PR on the
+      [docs repo](https://github.com/dgraph-io/dgraph-docs) staged and linked here. This process can
+      be simplified by going to the [public docs site](https://docs.dgraph.io/) and clicking the
+      "Edit this page" button at the bottom of page(s) relevant to your changes. Ensure that you
+      indicate in the PR that this is an **unreleased** feature so that it does not get merged into
+      the main docs prematurely.
 
 **Instructions**
 
-- The PR title should follow the [Conventional Commits](https://www.conventionalcommits.org/)
-  syntax, leading with `fix:`, `feat:`, `chore:`, `ci:`, etc.
+- The PR title should follow the
+  [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/#summary) syntax, leading
+  with `fix:`, `feat:`, `chore:`, `ci:`, etc. Ensure any breaking changes are appropriately marked
+  with a `!`. For instance, `feat(dql)!: Remove the foobar func` would indicate that this is a
+  breaking change to the DQL syntax.
 - The description should briefly explain what the PR is about. In the case of a bugfix, describe or
   link to the bug.
 - In the checklist section, check the boxes in that are applicable, using `[x]` syntax.

.github/workflows/cd-dgraph.yml

@@ -17,7 +17,7 @@ on:
         description: if checked, images will be pushed to dgraph-custom repo in Dockerhub
 
 permissions:
-  contents: read
+  contents: write
 
 jobs:
   dgraph-build-amd64:
@@ -260,6 +260,20 @@ jobs:
         with:
           name: dgraph-docker-arm64
 
+      # Download Dgraph Linux AMD64 Binary Artifacts
+      - name: Download Dgraph Linux AMD64 Binary Artifacts
+        uses: actions/download-artifact@v5
+        with:
+          name: dgraph-amd-release-artifacts
+          path: dgraph-amd-release-artifacts
+
+      # Download Dgraph Linux ARM64 Binary Artifacts
+      - name: Download Dgraph Linux ARM64 Binary Artifacts
+        uses: actions/download-artifact@v5
+        with:
+          name: dgraph-arm-release-artifacts
+          path: dgraph-arm-release-artifacts
+
       # Load Dgraph AMD64 Image
       - name: Load AMD64 Docker Image
         run: |
@@ -325,3 +339,18 @@ jobs:
                docker manifest push dgraph/dgraph:latest
             fi
           fi
+
+      - name: Upload Assets to Release
+        if: github.event.inputs.custom-build == 'false'
+        uses: softprops/action-gh-release@v2
+        with:
+          tag_name: ${{ github.event.inputs.releasetag }}
+          files: |
+            dgraph-amd-release-artifacts/dgraph/dgraph-linux-amd64.tar.gz
+            dgraph-amd-release-artifacts/dgraph/dgraph-checksum-linux-amd64.sha256
+            dgraph-amd-release-artifacts/badger/badger-linux-amd64.tar.gz
+            dgraph-amd-release-artifacts/badger/badger-checksum-linux-amd64.sha256
+            dgraph-arm-release-artifacts/dgraph/dgraph-linux-arm64.tar.gz
+            dgraph-arm-release-artifacts/dgraph/dgraph-checksum-linux-arm64.sha256
+            dgraph-arm-release-artifacts/badger/badger-linux-arm64.tar.gz
+            dgraph-arm-release-artifacts/badger/badger-checksum-linux-arm64.sha256

CONTRIBUTING.md

@@ -4,7 +4,7 @@
 - [Setting Up the Development Environment](#setting-up-the-development-environment)
   - [Prerequisites](#prerequisites)
   - [Setup Dgraph from source repo](#setup-dgraph-from-source-repo)
-  - [Setup Badger from source repo](#setup-badger-from-source-repo)
+  - [Setup Badger from source repo](#setup-badger-from-source-repo-optional)
   - [Protocol buffers](#protocol-buffers)
   - [Build Dgraph](#build-dgraph)
   - [Build Docker Image](#build-docker-image)
@@ -30,7 +30,10 @@
   available through your OS package manager)
 - Install [Docker](https://docs.docker.com/install/) and
   [Docker Compose](https://docs.docker.com/compose/install/).
-- [Install Go 1.22.12 or above](https://golang.org/doc/install).
+- [Install Go 1.24.3 or above](https://golang.org/doc/install).
+- Install
+  [trunk](https://docs.trunk.io/code-quality/overview/getting-started/install#install-the-launcher).
+  Our CI uses trunk to lint and check code, having it installed locally will save you time.
 
 ### Setup Dgraph from source repo
 
@@ -43,7 +46,7 @@ make install
 This will put the source code in a Git repo under `$GOPATH/src/github.com/dgraph-io/dgraph` and
 compile the binaries to `$GOPATH/bin`.
 
-### Setup Badger from source repo
+### Setup Badger from source repo (optional)
 
 Dgraph source repo vendors its own version of Badger. If you are just working on Dgraph, you do not
 necessarily need to check out Badger from its own repo. However, if you want to contribute to Badger
@@ -58,7 +61,7 @@ This will put the source code in a Git repo under `$GOPATH/src/github.com/dgraph
 ### Protocol buffers
 
 We use [protocol buffers](https://developers.google.com/protocol-buffers/) to serialize data between
-our server and the Go client and also for inter-worker communication. If you make any changes to the
+our server and our clients and also for inter-worker communication. If you make any changes to the
 `.proto` files, you would have to recompile them.
 
 Install the `protoc` compiler which is required for compiling proto files used for gRPC
@@ -117,6 +120,11 @@ Licensed variously under the Apache Public License 2.0 and Dgraph Community Lice
 © Istari Digital, Inc.
 ```
 
+#### Building Dgraph on non-Linux machines
+
+See the [README](t/README.md) in the [_t_](t) folder for instructions on building Dgraph on
+non-Linux machines.
+
 ### Build Docker Image
 
 ```sh
@@ -140,8 +148,8 @@ For dependencies, runner flags and instructions for running tests on non-Linux m
 [README](t/README.md) in the [_t_](t) folder.
 
 Other integration tests do not use the testing framework located in the `t` folder. Consult the
-[github actions definitions](.github) folder to discover the tests we run as part of our continuous
-delivery process.
+[github workflow definitions](.github/workflows) folder to discover the tests we run as part of our
+continuous integration process.
 
 Non-integration unit tests exist for many core packages that can be exercised without invoking the
 testing framework. For instance, to unit test the core DQL parsing package:
@@ -157,7 +165,9 @@ coding, or could be achieved by rewriting an entire module, that you may have pa
 yesterday.
 
 - **Pull requests are welcome**, as long as you're willing to put in the effort to meet the
-  guidelines. After you fork dgraph, create your pull request against our `main` branch
+  guidelines. After you fork Dgraph, create your pull request against our `main` branch. Please
+  follow the instructions in the PR template carefully.
+- Be prepared to document your additions/changes in our public documentation (if applicable)
 - Aim for clear, well written, maintainable code
 - Simple and minimal approach to features, like Go
 - New features must include passing unit tests, and integration tests when appropriate
@@ -172,7 +182,8 @@ yesterday.
 ### Code style
 
 - We're following [Go Code Review](https://github.com/golang/go/wiki/CodeReviewComments)
-- Use `go fmt` to format your code before committing
+- At a minimum, use `go fmt` to format your code before committing. Ideally you should use `trunk`
+  as our CI will run `trunk` on your code
 - If you see _any code_ which clearly violates the style guide, please fix it and send a pull
   request. No need to ask for permission
 - Avoid unnecessary vertical spaces. Use your judgment or follow the code review comments

contrib/RELEASE.md

@@ -0,0 +1,55 @@
+# Dgraph Release Process
+
+This document outlines the steps needed to build and push a new release of Dgraph.
+
+1. Have a team member "at-the-ready" with github `writer` access (you'll need them to approve PRs).
+1. Create a new branch (prepare-for-release-vXX.X.X, for instance).
+1. Update dependencies in `go.mod` for Badger, Ristretto and Dgo, if required.
+1. If you didn't update `go.mod`, decide if you need to run the weekly upgrade CI workflow,
+   [ci-dgraph-weekly-upgrade-tests](https://github.com/dgraph-io/dgraph/actions/workflows/ci-dgraph-weekly-upgrade-tests.yml),
+   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).
+1. Update the CHANGELOG.md. Sonnet 4.5 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.`.
+1. 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.
+1. 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.
+1. Using the updated CHANGELOG.md as a guide, ensure that user-facing additions or changes have appropriate PRs in
+   the Dgraph [docs repo](https://github.com/dgraph-io/dgraph-docs/).
+1. Once your "prepare for release branch" is merged into main, on the github
+   [releases](https://github.com/dgraph-io/dgraph/releases) page, create a new draft release (this step
+   will create the tag, in this example we're releasing _v25.1.0-preview1_):
+   <img width="1491" height="745" alt="image" src="https://github.com/user-attachments/assets/18a2af83-9345-48fc-95cf-368ea4f0a70e" />
+   Note: check the toggle to create a Annoucement in our Discussions forum (time saver).
+1. Start the deployment workflow from
+   [here](https://github.com/dgraph-io/dgraph/actions/workflows/cd-dgraph.yml):
+   <img width="1491" height="745" alt="image" src="https://github.com/user-attachments/assets/9f3801d1-56dd-4bfe-acdb-9f1518b0bf13" />
+   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.
+
+1. Verify the push
+   1. Ensure the image tags are pushed to
+      [https://hub.docker.com/r/dgraph/dgraph/tags](https://hub.docker.com/r/dgraph/dgraph/tags)
+   1. Run this command to verify the version: `docker run dgraph/dgraph:vXX.X.X dgraph version`
+   1. 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)
+1. 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
+   ```
+1. Check the [Discussions](https://github.com/orgs/dgraph-io/discussions) forum for the announcement
+   of the release (create one if you forgot that step above which autocreates one).
+1. If the release has documentation changes, alert the docs team to merge the doc changes in the 
+   [dgraph-docs](https://github.com/dgraph-io/dgraph-docs/) repo.