You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/releases/release-process.md
+50-6Lines changed: 50 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -28,7 +28,32 @@ From RC3 onward, RCs are cut **more frequently and as needed**, rather than stri
28
28
29
29
## Golden Values
30
30
31
-
Golden values are reference outputs used to validate model behavior in CI.
31
+
Golden values are reference outputs used to validate model behavior in CI. They live in the **internal CI repository** and are the baseline for the internal regression tracker — keeping them current and accurate is therefore critical for meaningful signal.
32
+
33
+
### When to update golden values
34
+
35
+
Any PR that can affect performance metrics (e.g. changes to model code, training loop, optimizer, or numerical kernels) **must be accompanied by a corresponding internal PR that updates the golden values** before merging. Do not wait until after the PR lands.
36
+
37
+
### Updating golden values for PRs targeting `main`
38
+
39
+
1.**Rebase the MBridge PR against `main`** so it is at top-of-tree before launching CI.
40
+
2.**Launch an internal CI run** using:
41
+
- The **latest nightly container** as the base image.
42
+
- The **latest MCore commit** on `main`.
43
+
- The **MBridge PR commit** (the head of your MBridge branch).
44
+
3. Collect the outputs and open a PR against the **internal CI repository's `main` branch** with the updated golden values.
45
+
4. The MBridge PR and the internal golden-values PR should be merged together (or the golden-values PR first).
46
+
47
+
### Updating golden values during a release
48
+
49
+
When golden values need to be refreshed on the release branch (e.g. at the start of code-freeze or after an accepted regression):
50
+
51
+
1.**Rebase the MBridge PR against the MBridge release branch** so it is at the head of that branch.
52
+
2.**Launch an internal CI run** using:
53
+
- The **latest internal RC container** for the release.
54
+
- The **MCore commit pinned on the release branch**.
55
+
- The **MBridge PR commit** (head of the MBridge release branch).
56
+
3. Open a PR against the **internal CI repository's release branch** with the updated golden values.
32
57
33
58
### During the RC Phase (before code-freeze)
34
59
@@ -41,24 +66,26 @@ This means golden values are not automatically updated with every run — a deli
41
66
42
67
### On the Release Branch (during code-freeze)
43
68
44
-
When the release branch is created at code-freeze, all golden values are updated **unconditionally**. Whatever the current output is becomes the new reference baseline for the release.
69
+
When the release branch is created at code-freeze, all golden values are updated **unconditionally** — whatever the current output is becomes the new reference baseline for the release.
70
+
71
+
In **Week 5**, the last bulk update of golden values is performed. After that point, engineers are individually responsible for updating any remaining golden values on the release branch, reviewing discrepancies and ensuring the suite is clean ahead of the release.
45
72
46
73
-----
47
74
48
75
## Code-Freeze
49
76
50
77
Code-freeze lasts **two weeks** and begins when RC3 is cut. This is the **stabilization phase** — no new features are landed.
51
78
52
-
### First Half
79
+
### First Half (Weeks 3–5)
53
80
54
81
-**Release branches are created.**
55
82
- All golden values on the release branch are updated unconditionally (see above).
56
-
- The **last bulk CI run**occurs one week into the code-freeze period.
83
+
- The **last bulk update of golden values**happens in **Week 5**.
57
84
- RCs continue to be cut as needed.
58
85
59
-
### Second Half
86
+
### Second Half (Weeks 6–7)
60
87
61
-
-**Engineers are responsible for updating golden values** on the release branch — reviewing any remaining discrepancies and ensuring the suite is in a clean state ahead of release.
88
+
-**Engineers are individually responsible for updating golden values** on the release branch — reviewing any remaining discrepancies and ensuring the suite is in a clean state ahead of release.
62
89
- RCs continue to be cut as needed.
63
90
64
91
### Release Day
@@ -67,6 +94,23 @@ The release goes out on the **first Wednesday after the code-freeze window ends*
67
94
68
95
-----
69
96
97
+
## Patch Release
98
+
99
+
After the main release ships (Week 7, typically mid-month), the release branches are **reopened** for contributions targeting the patch release.
100
+
101
+
### Patch Release Timeline
102
+
103
+
| Period | Approximate Timing | Key Activity |
104
+
|--------|--------------------|--------------|
105
+
| Reopening | Release day (Week 7) | Branches accept contributions; patch development begins |
106
+
| Lockdown | First Monday of the following month (~2 weeks later) | Release branches locked; **patch RC0 (`XX.YY.01.RC0`) shipped internally**|
107
+
| Stabilization | Week 1–2 after RC0 | Bug fixes and small improvements only |
108
+
|| End of Week 2 | QA exit, patch release |
109
+
110
+
The patch stabilization flow mirrors the main release's code-freeze phase, but compressed into approximately two weeks.
0 commit comments