Skip to content

Commit 0bf8640

Browse files
KaveeshaPiuminiKaveeshaPiumini
committed
Add release process documentation
1 parent 35a9596 commit 0bf8640

2 files changed

Lines changed: 88 additions & 0 deletions

File tree

‎docs/content/community/contributing/overview.mdx‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -24,6 +24,7 @@ Thunder welcomes different types of contributions, and you can participate at an
2424
| **Share Ideas & Define Problems** | [Problem definition](#-sharing-ideas--defining-problems) |
2525
| **Design Features** | [Design proposals](#-designing-solutions) |
2626
| **Implement Features** | [Development guide](development.md) |
27+
| **Release Operations** | [Release process](release-process) |
2728

2829
**You don't need to do everything!** You can:
2930

‎docs/content/community/contributing/release-process.mdx‎

Lines changed: 87 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,87 @@
1+
---
2+
title: Release Process
3+
description: Learn the weekly release rhythm, validation model, and release execution process for Thunder.
4+
sidebar_position: 4
5+
hide_table_of_contents: false
6+
---
7+
8+
# Release Process
9+
10+
This page explains how Thunder moves changes from development to a weekly release.
11+
12+
---
13+
14+
## 📅 Release Cadence
15+
16+
Thunder follows a weekly release cycle. Work is planned, developed, and validated within a fixed weekly window.
17+
18+
| Day | Activity |
19+
| --- | --- |
20+
| Monday | Weekly sync to plan the milestone, assign work, and confirm scope |
21+
| Monday to Thursday | Development, pull requests, reviews, and iteration |
22+
| Thursday night | Code freeze and release branch sync |
23+
| Friday | Validate milestone changes, fix or revert issues, then release |
24+
25+
---
26+
27+
## Branch Model
28+
29+
```text
30+
main ──●──●──●──●──┬──●──●──●──── (development continues)
31+
│
32+
└── release ──○──○──◆ tag vX.Y.Z
33+
│ │ │
34+
fixes merge back to main
35+
validated and delete branch
36+
```
37+
38+
Development happens continuously on `main`. On Thursday night, a `release` branch is cut from `main`. Any fixes identified during release validation are applied directly to the release branch. Once everything is validated and the release is confirmed good, it is tagged and the branch is merged back into `main` and deleted.
39+
40+
---
41+
42+
## 🧪 Release Validation
43+
44+
Every change included in the milestone must be validated by someone other than the author before release.
45+
46+
In addition to milestone-specific changes, **core IAM flows** — including authentication, authorization, and token management — are tested every release, regardless of what changed. This ensures baseline functionality is never silently broken between releases.
47+
48+
---
49+
50+
## 🔖 Release Manager Responsibilities
51+
52+
The Release Manager coordinates release readiness and final release execution.
53+
54+
1. **Lead the weekly sync** — confirm milestone scope and identify at-risk work.
55+
2. **Review readiness on Thursday** — check milestone issues and pull requests for blockers.
56+
3. **Create a draft release** — publish a draft GitHub release to verify release artifacts before going live.
57+
4. **Coordinate release validation** — confirm all milestone changes are validated against the draft release.
58+
5. **Trigger the Release Builder** — run the workflow manually once everything is confirmed good to release, or allow the scheduled release run.
59+
6. **Confirm post-release sync** — verify the release branch is synchronized back to main, ensure the milestone is closed and release notes are generated properly, and update stakeholders.
60+
61+
---
62+
63+
## 🚨 When Issues Arise
64+
65+
> **Default stance: revert and release on time.**
66+
67+
| Situation | Action |
68+
| --- | --- |
69+
| Milestone change fails and quick fix is clear | Author fixes on release branch and re-validates |
70+
| Milestone change fails and fix is complex | Revert from release branch, release without it, carry to next week |
71+
| Release validation fails and cause is clear | Revert causing change and release without it |
72+
| Release validation fails and cause is unclear | Revert suspected change and investigate on main next week |
73+
74+
A predictable release train matters more than any single feature.
75+
76+
---
77+
78+
## ⚙️ Automation Workflows
79+
80+
The weekly release process uses these GitHub Actions workflows:
81+
82+
| Workflow | Trigger | What It Does |
83+
| --- | --- | --- |
84+
| [Pre-Release Sync](https://github.com/asgardeo/thunder/blob/main/.github/workflows/pre-release-sync.yml) | Scheduled on Thursday night (UTC) and manual dispatch | Creates the release branch and syncs the latest changes from main |
85+
| [Release Milestone Reminder](https://github.com/asgardeo/thunder/blob/main/.github/workflows/release-milestone-reminder.yaml) | Scheduled every Thursday and manual dispatch | Sends release-readiness reminder based on open milestone items |
86+
| [Release Builder](https://github.com/asgardeo/thunder/blob/main/.github/workflows/release-builder.yml) | Scheduled on Friday and manual dispatch | Builds, tags, packages, and publishes the release |
87+
| [Post-Release Sync](https://github.com/asgardeo/thunder/blob/main/.github/workflows/post-release-sync.yml) | After successful release workflow run and manual dispatch | Syncs release back into main, deletes release branch, or opens a conflict-resolution pull request |

0 commit comments

Comments
 (0)