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/creating-a-release.md
+27-32
Original file line number
Diff line number
Diff line change
@@ -17,11 +17,12 @@ _This document applies to normal releases, off of `main`. For hotfixing a prior
17
17
18
18
### First week of sprint
19
19
20
-
-[Step 0.1: Ensure strings are Updated on Main](#step-01-ensure-strings-are-updated-on-main)
20
+
-[Step 0.1: Create a Thread in the WebUI channel to Track Release Progress](#step-01-create-a-thread-in-the-webui-channel-to-track-release-progress)
21
21
-[Step 0.2: Pre-Release ChangeLog and Update Feature List](#step-02-pre-release-changelog-and-update-feature-list)
22
-
-[Step 0.3: Create a Thread in the WebUI channel to Track Release Progress](#step-03-create-a-thread-in-the-webui-channel-to-track-release-progress)
22
+
-[Step 0.3: ARB Review of any Changes to Public SDK API and/or Rest APi (Required for Stable | Recommended for Beta)](#step-03-arb-review-of-any-changes-to-public-sdk-api-andor-rest-api-required-for-stable--recommended-for-beta)
23
23
-[Step 0.4: Create an Async Bug Bash Meeting](#step-04-create-an-async-bug-bash-meeting)
24
-
-[Step 0.5: ARB Review of any public API changes (Required for Stable | Recommended for Beta)](#step-05-arb-review-of-any-public-api-changes-required-for-stable--recommended-for-beta)
24
+
-[Step 0.5: Create a Change Log Grooming Meeting](#step-05-create-a-change-log-grooming-meeting)
25
+
-[Step 0.6: Ensure strings are Updated on Main](#step-06-ensure-strings-are-updated-on-main)
25
26
26
27
### Second week of sprint
27
28
@@ -35,9 +36,8 @@ _This document applies to normal releases, off of `main`. For hotfixing a prior
35
36
36
37
#### Tuesday / Wednesday
37
38
38
-
-[Step 2.1: (Stable Only): API approval from Azure REST API stewardship board](#step-21-stable-only-api-approval-from-azure-rest-api-stewardship-board)
### Step 0.3: Create a Thread in the WebUI channel to Track Release Progress
67
+
### Step 0.3: ARB Review of any Changes to Public SDK API and/or Rest APi (Required for Stable | Recommended for Beta)
69
68
70
-
Create a release thread in the WebUI channel and keep it up to date so the whole team knows where we are at.
69
+
1.[Create an APIView](https://skype.visualstudio.com/SPOOL/_wiki/wikis/SPOOL.wiki/48971/Creating-an-APIView) showing changes.
70
+
1. Create a post in `Language - JavaScript - Reviews` channel with APIView link to request review.
71
+
1. Use a previous review request as an example.
72
+
1. See the [internal documentation](https://skype.visualstudio.com/SPOOL/_wiki/wikis/SPOOL.wiki/27654/Scheduling-an-Azure-Review-Board-%28ARB%29-Review) for how to reach out to the API stewardship board.
73
+
1. Follow up after 24-48 hours if you have not received a response.
### step 0.5: ARB Review of any public API changes (Required for Stable | Recommended for Beta)
82
+
### Step 0.5: Create a Change Log Grooming Meeting
80
83
81
-
1. Create an APIView showing changes.
82
-
1. Create a post in `Language - JavaScript - Reviews` channel with APIView link to request review.
83
-
1. Use a previous review request as an example.
84
+
Setup a meeting with the feature owners to groom the changelog together.
85
+
86
+
### Step 0.6: Ensure Strings are updated on Main
87
+
88
+
- String translation take up to 5 working days to complete. **Any PR changing strings needs to be complete 5 working days before release.**
89
+
-[Ensure any strings PRs are merged into `main`](../references/string-translations.md)
84
90
85
91
## Step 1: Creating a Release Branch
86
92
@@ -94,6 +100,8 @@ Use the [create-prerelease-branch](https://github.com/Azure/communication-ui-lib
94
100
95
101
1. Options for this workflow:
96
102
1. Branch - This is the branch that the release will be created from. Default option is from `main`.
103
+
1. Get current version from [communication-react package.json](https://github.com/Azure/communication-ui-library/blob/main/packages/communication-react/package.json).
104
+
1. Use this version as the basis for making your decision in the next step.
97
105
1. Bump Type - This is the type of release that will be created, the options for this are:
98
106
-`beta-release-major` - Choose this option when you want to release from `1.2.0 -> 2.0.0-beta.1`
99
107
-`beta-release-minor` - Choose this option when you want to release from `1.2.0 -> 1.3.0-beta.1` or `1.2.0-beta.3 -> 1.3.0-beta.1`
@@ -154,29 +162,16 @@ After finishing creating a release branch, follow these steps to create a UI sna
154
162
1. Once the snapshot update is finished, you might or might not see changes for the UI snapshot, if there are any updates, open a PR to merge that new branch back to the release branch
155
163
1. Merge the PR if everything looks fine, or notify the feature owner if something looks not 100% correct.
156
164
157
-
### Step 1.5 (Beta Only): Notify the Release Thread About api.md Update and UI Snapshot Update
158
-
159
-
After you finish step 1.3, you can check recent latest commits on the release branch, there should be
160
-
161
-
1. One Api snapshot update commit
162
-
1. 0 or several UI snapshot commits, all in the snapshot PR
163
-
164
-
Copy links to those snapshot commits and UI snapshot PR link, and post them in the release thread, ask feature owners to check if their features are correctly removed both in API and UI
165
-
166
-
## Step 2: Prepare for release
167
-
168
-
### Step 2.1 (Stable Only): API approval from Azure REST API stewardship board
169
-
170
-
For stable release, we must get any API changes approved by the Azure REST API Stewardship board. See the [internal documentation](https://skype.visualstudio.com/SPOOL/_wiki/wikis/SPOOL.wiki/27654/Scheduling-an-Azure-Review-Board-%28ARB%29-Review) for how to reach out to the API stewardship board.
165
+
## Step 2: Prepare for Release
171
166
172
-
### Step 2.2: Bug Bash
167
+
### Step 2.1: Bug Bash
173
168
174
169
Once the release branch has been created, we must make sure that the package we eventually off of the release branch is high quality. Towards this:
175
170
176
171
- Set up a bug bash with the team to shake out any issues. See [internal documentation](https://skype.visualstudio.com/SPOOL/_wiki/wikis/SPOOL.wiki/31350/WebUI-Setting-up-a-bug-bash) for setting up a bug bash.
177
172
- Triage bugs found via bug bash and manage merging of fixes into the release branch, as described in the section below.
178
173
179
-
#### Cherry-picking changes
174
+
#### Cherry-picking Changes
180
175
181
176
While the release branch is active, some changes might be merged into the branch (for bug fixes, or features deemed necessary for the release). PRs into the release branch should follow this process when possible:
182
177
@@ -190,7 +185,7 @@ This process has the following benefits:
190
185
- The release branch never diverges off of `main`. In theory, it is possible to abandon the release branch at any point and create a new one off of `main` without losing work.
191
186
- All PR reviews happen on `main`, and the cherry-pick PR simply requires a sign-off.
192
187
193
-
### Step 2.3: Fetch translated strings
188
+
### Step 2.2: Fetch, Merge and Cherry-pick Translated Strings
194
189
195
190
[Fetch translated strings](https://github.com/Azure/communication-ui-library/blob/main/docs/references/string-translations.md) again for main to make sure any other string updates that have occurred since the start of the release process are included. If there are any strings updated, cherry-pick the changes to the release branch.
0 commit comments