|
| 1 | +# Release Guide |
| 2 | + |
| 3 | +This document provides a step-by-step guide to creating a new release for the **mediator** by triggering the workflow. |
| 4 | + |
| 5 | +--- |
| 6 | + |
| 7 | +## Prerequisites |
| 8 | + |
| 9 | +Before proceeding, ensure you have the following: |
| 10 | + |
| 11 | +- Write access to the repository. |
| 12 | +- A local copy of the repository with the latest `main` branch. |
| 13 | +- Git installed on your machine. |
| 14 | +- Familiarity with the existing GitHub Actions workflow for the release process. |
| 15 | + |
| 16 | +--- |
| 17 | + |
| 18 | +## Release Process |
| 19 | + |
| 20 | +### Step 1: Create a New Branch |
| 21 | + |
| 22 | +1. Pull the latest changes from the `main` branch to ensure you are up to date: |
| 23 | + ```bash |
| 24 | + git checkout main |
| 25 | + git pull origin main |
| 26 | + ``` |
| 27 | + |
| 28 | +2. Create a new release branch: |
| 29 | + ```bash |
| 30 | + git checkout -b vX.Y.Z |
| 31 | + ``` |
| 32 | + Replace `vX.Y.Z` with the version you plan to release, e.g., `v0.1.2`. |
| 33 | + |
| 34 | +### Step 2: Determine the Next Tag Version |
| 35 | + |
| 36 | +1. Identify the latest tag in the repository: |
| 37 | + ```bash |
| 38 | + git tag --list --sort=-v:refname | head -n 1 |
| 39 | + ``` |
| 40 | + For example, if the latest tag is `v0.1.1`, the next tag should be `v0.1.2`. |
| 41 | + |
| 42 | +2. Follow semantic versioning to increment the tag appropriately: |
| 43 | + |
| 44 | +* Increment the patch version for bug fixes (e.g., `v0.1.1` → `v0.1.2`). |
| 45 | +* Increment the minor version for new features (e.g., `v0.1.1` → `v0.2.0`). |
| 46 | +* Increment the major version for breaking changes (e.g., `v0.1.1` → `v1.0.0`). |
| 47 | + |
| 48 | +### Step 3: Create the New Tag |
| 49 | + |
| 50 | +1. Create a new Git tag locally: |
| 51 | + ```bash |
| 52 | + git tag vX.Y.Z |
| 53 | + ``` |
| 54 | + Replace vX.Y.Z with the new version, e.g., `v0.1.2`. |
| 55 | + |
| 56 | +2. Push the tag to the remote repository: |
| 57 | + ```bash |
| 58 | + git push origin vX.Y.Z |
| 59 | + ``` |
| 60 | + |
| 61 | +### Step 4: Trigger the Release Workflow |
| 62 | + |
| 63 | +* The GitHub Actions workflow is automatically triggered when a tag like `v0.1.2` is pushed. |
| 64 | + |
| 65 | +* Monitor the progress of the workflow in the Actions tab on GitHub to ensure the release completes successfully. |
| 66 | + |
| 67 | + |
| 68 | +### Notes on the Workflow |
| 69 | + |
| 70 | +The workflow performs the following tasks automatically: |
| 71 | + |
| 72 | +* Build and Test: The codebase is built and tested to ensure stability. |
| 73 | + |
| 74 | +* Binary Artifact Creation: The release binary is saved as an artifact. |
| 75 | + |
| 76 | +* GitHub Release Creation: A release is created in the repository, including: |
| 77 | + |
| 78 | + * The release binary as an artifact. |
| 79 | + |
| 80 | + * A release note template. |
0 commit comments