@workday/canvas-kit-docs 7.3.1 → 7.3.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/mdx/MAINTAINING.mdx +246 -0
- package/package.json +3 -3
|
@@ -0,0 +1,246 @@
|
|
|
1
|
+
# Maintaining Canvas Kit
|
|
2
|
+
|
|
3
|
+
If you're a Canvas Kit core maintainer, this doc is for you! Consider this a field guide to help you
|
|
4
|
+
maintain Canvas Kit with confidence. If you see some information that's unclear, incomplete, or
|
|
5
|
+
incorrect, please update this doc to help your future self and others. Thanks for maintaining Canvas
|
|
6
|
+
Kit!
|
|
7
|
+
|
|
8
|
+
- [Branches](#branches)
|
|
9
|
+
- [GitHub Actions](#github-actions)
|
|
10
|
+
- [Forward Merge Workflow](#forward-merge-workflow)
|
|
11
|
+
- [Release Minor Workflow](#release-minor-workflow)
|
|
12
|
+
- [Release Workflow](#release-workflow)
|
|
13
|
+
- [Releases](#releases)
|
|
14
|
+
- [Patch Releases](#patch-releases)
|
|
15
|
+
- [Minor Releases](#minor-releases)
|
|
16
|
+
- [Major Releases](#major-releases)
|
|
17
|
+
- [Canary Releases](#canary-releases)
|
|
18
|
+
|
|
19
|
+
## Branches
|
|
20
|
+
|
|
21
|
+
We maintain three major versions of Canvas Kit at any given time: the previous major, the current
|
|
22
|
+
major, and the next major version. These versions live in four branches:
|
|
23
|
+
|
|
24
|
+
- `support` - the previous major version - patches only, no new features or breaking changes
|
|
25
|
+
- `master` - the current major version - patches and small updates only
|
|
26
|
+
- `prerelease/minor` - the current major version - new features are added here
|
|
27
|
+
- `prerelease/major` - the next major version - patches, new features, and major breaking changes
|
|
28
|
+
|
|
29
|
+
## GitHub Actions
|
|
30
|
+
|
|
31
|
+
We use [GitHub Actions](https://docs.github.com/en/actions) to automate our workflows and CI / CD
|
|
32
|
+
processes. You can view all our workflows [here](https://github.com/Workday/canvas-kit/actions).
|
|
33
|
+
|
|
34
|
+
### Forward Merge Workflow
|
|
35
|
+
|
|
36
|
+
Forward merges ensure that changes made in lower-versioned branches are forwarded to
|
|
37
|
+
higher-versioned branches. So for example, if a bug is patched in the `support` branch, forward
|
|
38
|
+
merging propogates the fix so it's available in `master`, `prerelease/minor` and `prerelease/major`
|
|
39
|
+
branches. This workflow is fully automated, which reduces opportunities for error.
|
|
40
|
+
|
|
41
|
+
The
|
|
42
|
+
[forward merge workflow](https://github.com/Workday/canvas-kit/actions/workflows/forward-merge.yml)
|
|
43
|
+
runs on `support`, `master`, and `prerelease/minor` branches. Forward merges for `support` and
|
|
44
|
+
`master` run automatically when a release commit is merged to that branch. Every release commit
|
|
45
|
+
starts with `chore: Release`, and that's how the forward merge workflow identifies them. Forward
|
|
46
|
+
merges will run on every merge to `prerelease/minor` regardless of the commit message.
|
|
47
|
+
|
|
48
|
+
| Run Forward Merge? | Branch | Commit Message |
|
|
49
|
+
| ------------------ | ------------------ | --------------------------------------- |
|
|
50
|
+
| ✅ | `support` | `chore: Release v6.8.14 [skip release]` |
|
|
51
|
+
| ⛔️ | `support` | `fix: Remove unused props` |
|
|
52
|
+
| ✅ | `master` | `chore: Release v7.3.0 [skip release]` |
|
|
53
|
+
| ⛔️ | `master` | `fix: Update Popup types` |
|
|
54
|
+
| ✅ | `prerelease/minor` | `feat: Add new Layout components` |
|
|
55
|
+
|
|
56
|
+
If the forward merge workflow fails and cannot automatically merge the update to the next branch, it
|
|
57
|
+
will generate a PR with instructions on how to handle the forward merge manually. For a more
|
|
58
|
+
in-depth review,
|
|
59
|
+
[view the workflow source code](https://github.com/Workday/canvas-kit/blob/master/.github/workflows/forward-merge.yml).
|
|
60
|
+
|
|
61
|
+
### Release Minor Workflow
|
|
62
|
+
|
|
63
|
+
The
|
|
64
|
+
[release minor workflow](https://github.com/Workday/canvas-kit/blob/master/.github/workflows/release-minor.yml)
|
|
65
|
+
is initated manually and begins the process for [minor releases](#minor-releases). It checks out the
|
|
66
|
+
`prerelease/minor` branch and pushes any commits not in `master` to the master branch. It does not
|
|
67
|
+
run any tests or validations as all the commits have been verified by the previous workflows. Once
|
|
68
|
+
`prerelease/minor` is merged to `master`, it will trigger the [release workflow](#release-workflow)
|
|
69
|
+
which will publish a new version of Canvas Kit.
|
|
70
|
+
|
|
71
|
+
This workflow will only fail if there are commits in `master` that are not included in
|
|
72
|
+
`prerelease/minor`. You can verify that
|
|
73
|
+
[here](https://github.com/Workday/canvas-kit/compare/prerelease/minor...master). In that case,
|
|
74
|
+
you'll need to [foward merge](#forward-merge-workflow) any commits in `master` to
|
|
75
|
+
`prerelease/minor`. For a more in-depth review of the workflow,
|
|
76
|
+
[view the source code](https://github.com/Workday/canvas-kit/blob/master/.github/workflows/release-minor.yml).
|
|
77
|
+
|
|
78
|
+
### Release Workflow
|
|
79
|
+
|
|
80
|
+
The
|
|
81
|
+
[release workflow](https://github.com/Workday/canvas-kit/blob/master/.github/workflows/release-minor.yml)
|
|
82
|
+
is initiated automatically and runs the release process for all Canvas Kit releases (major, minor,
|
|
83
|
+
and patch) on the `master` and `support` branches. This workflow will only run if:
|
|
84
|
+
|
|
85
|
+
- The commit message does not contain `[skip release]`
|
|
86
|
+
- OR the workflow was manually triggered and has a `version` string
|
|
87
|
+
|
|
88
|
+
At a high-level, this workflow will:
|
|
89
|
+
|
|
90
|
+
- checkout the repository
|
|
91
|
+
- install dependencies (if they are not already cached)
|
|
92
|
+
- run `yarn bump` to craete a commit and a git tag
|
|
93
|
+
- bump package versions
|
|
94
|
+
- generate a changeset
|
|
95
|
+
- update the changelog
|
|
96
|
+
- build Storybook
|
|
97
|
+
- publish to npm
|
|
98
|
+
- create a GitHub release
|
|
99
|
+
- publish Storybook
|
|
100
|
+
- update Chromatic baseline
|
|
101
|
+
- notify Slack
|
|
102
|
+
|
|
103
|
+
For a more in-depth review of the workflow,
|
|
104
|
+
[view the source code](https://github.com/Workday/canvas-kit/blob/master/.github/workflows/release.yml)
|
|
105
|
+
|
|
106
|
+
### Canary Workflow
|
|
107
|
+
|
|
108
|
+
The
|
|
109
|
+
[canary workflow](https://github.com/Workday/canvas-kit/blob/master/.github/workflows/release-minor.yml)
|
|
110
|
+
are initiated automatically when a commit is merged to `prerelease/minor` or `prerelease/major`. For
|
|
111
|
+
a more in-depth review of the workflow,
|
|
112
|
+
[view the source code](https://github.com/Workday/canvas-kit/blob/master/.github/workflows/release-minor.yml).
|
|
113
|
+
|
|
114
|
+
## Releases
|
|
115
|
+
|
|
116
|
+
### Patch Releases
|
|
117
|
+
|
|
118
|
+
Patch releases in the `support` and `master` branches go out automatically once the pull request is
|
|
119
|
+
merged. These releases use the [release workflow](#release-workflow) to publish updates
|
|
120
|
+
automatically.
|
|
121
|
+
|
|
122
|
+
### Minor Releases
|
|
123
|
+
|
|
124
|
+
Canvas Kit minor releases occur every three weeks. They are initiated manually by a maintainer with
|
|
125
|
+
the [release minor workflow](#release-minor-workflow). Before you initiate a minor release, all
|
|
126
|
+
branches up to `prerelease/minor` need to be [forward merged](#forward-merge-workflow). Check all of
|
|
127
|
+
the following to make sure there are no commits listed:
|
|
128
|
+
|
|
129
|
+
- [Compare](https://github.com/Workday/canvas-kit/compare/master...support) `master` with `support`
|
|
130
|
+
- [Compare](https://github.com/Workday/canvas-kit/compare/prerelease/minor...master)
|
|
131
|
+
`prerelease/minor` with `master`
|
|
132
|
+
|
|
133
|
+
If there are any commits listed, run the
|
|
134
|
+
[forward merge](https://github.com/Workday/canvas-kit/actions/workflows/forward-merge.yml) for the
|
|
135
|
+
branch that isn't merged forward (`support`, `master`, or `prerelease/minor`). It is safe to run
|
|
136
|
+
this job even if there are no changes since the job will recognize no change and bail.
|
|
137
|
+
|
|
138
|
+
### Major Releases
|
|
139
|
+
|
|
140
|
+
Canvas Kit major releases occur every six months. They are manual and performed by a maintainer. The
|
|
141
|
+
process is similar to minor releases, except the addition of the support branch. All branches have
|
|
142
|
+
to be forward merged. Check all of the following to make sure there are no commits listed:
|
|
143
|
+
|
|
144
|
+
- [Compare](https://github.com/Workday/canvas-kit/compare/master...support) `master` with `support`
|
|
145
|
+
- [Compare](https://github.com/Workday/canvas-kit/compare/prerelease/minor...master)
|
|
146
|
+
`prerelease/minor` with `master`
|
|
147
|
+
- [Compare](https://github.com/Workday/canvas-kit/compare/prerelease/major...prerelease/minor)
|
|
148
|
+
`prerelease/major` with `prerelease/minor`
|
|
149
|
+
|
|
150
|
+
If there are any commits listed, run the
|
|
151
|
+
[forward merge](https://github.com/Workday/canvas-kit/actions/workflows/forward-merge.yml) for the
|
|
152
|
+
branch that isn't merged forward (`support`, `master`, or `prerelease/minor`). It is safe to run
|
|
153
|
+
this job even if there are no changes since the job will recognize no change and bail.
|
|
154
|
+
|
|
155
|
+
We'll be using the terms `previous major`, `current major`, and `next major` in the context of
|
|
156
|
+
versions before the release process is complete. For example, if `support` is pointing to v4,
|
|
157
|
+
`master` to v5 and `prerelease/major` to v6, we need to update these pointers. After these steps are
|
|
158
|
+
completed, the following will happen:
|
|
159
|
+
|
|
160
|
+
- `support`: v4 -> v5
|
|
161
|
+
- `master`: v5 -> v6
|
|
162
|
+
- `prerelease/minor`: v5 -> v6
|
|
163
|
+
- `prerelease/major`: v6 -> v7
|
|
164
|
+
|
|
165
|
+
Before starting the next steps, make sure to fetch upstream.
|
|
166
|
+
|
|
167
|
+
```sh
|
|
168
|
+
git fetch upstream
|
|
169
|
+
```
|
|
170
|
+
|
|
171
|
+
1. Update `support` to point to the current major version `master` is currently pointing to. We need
|
|
172
|
+
an empty commit with [no-release] to skip the normal release process on the support branch. If we
|
|
173
|
+
don't add this commit, the job will fail to create an npm version that is already published.
|
|
174
|
+
|
|
175
|
+
```sh
|
|
176
|
+
git checkout support
|
|
177
|
+
git pull upstream support
|
|
178
|
+
git pull upstream master
|
|
179
|
+
git commit --allow-empty --no-verify -m "Bump support to next major version [skip release]"
|
|
180
|
+
git push upstream support
|
|
181
|
+
```
|
|
182
|
+
|
|
183
|
+
This will trigger a support release job that should skip publishing. We do not need to wait for this
|
|
184
|
+
job.
|
|
185
|
+
|
|
186
|
+
2. Update `master` to point to the next major release `prerelease/major` is currently pointing to.
|
|
187
|
+
This step produces the actual release, including a Slack message.
|
|
188
|
+
|
|
189
|
+
```sh
|
|
190
|
+
git checkout master
|
|
191
|
+
git pull upstream master
|
|
192
|
+
git pull upstream prerelease/major
|
|
193
|
+
git push upstream master
|
|
194
|
+
```
|
|
195
|
+
|
|
196
|
+
This will trigger the
|
|
197
|
+
[release workflow](https://github.com/Workday/canvas-kit/actions/workflows/release.yml). Up to this
|
|
198
|
+
point, `prerelease/major` has been creating canary jobs. This will trigger the actual release. We
|
|
199
|
+
must wait for this job to finish. The job will be running against `master`. The CI job will run
|
|
200
|
+
`lerna bump` and push that commit back onto the `master` branch which will include the update to
|
|
201
|
+
`lerna.json` that we need in the next step.
|
|
202
|
+
|
|
203
|
+
3. Once the previous step is completed, we need to update `prerelease/minor` to point to the next
|
|
204
|
+
major release. After this step, any PRs against this branch will be correct.
|
|
205
|
+
|
|
206
|
+
```sh
|
|
207
|
+
git checkout prerelease/minor
|
|
208
|
+
git pull upstream prerelease/minor
|
|
209
|
+
git pull upstream master
|
|
210
|
+
git commit --allow-empty --no-verify -m "Bump prerelease/minor to new major version [skip release]"
|
|
211
|
+
git push upstream prerelease/minor
|
|
212
|
+
```
|
|
213
|
+
|
|
214
|
+
4. Now we need to update `prerelease/major` with the changes we made to `prerelease/minor` which
|
|
215
|
+
include the major release version bump. This will point the canary build to the next next major
|
|
216
|
+
version. For example, if `prerelease/major` was pointing to v6 before our release, it will now
|
|
217
|
+
point to v7.
|
|
218
|
+
|
|
219
|
+
```sh
|
|
220
|
+
git checkout prerelease/major
|
|
221
|
+
git pull upstream prerelease/major
|
|
222
|
+
git pull upstream prerelease/minor
|
|
223
|
+
git push upstream prerelease/major
|
|
224
|
+
```
|
|
225
|
+
|
|
226
|
+
### Canary Releases
|
|
227
|
+
|
|
228
|
+
Canary releases use the [canary workflow](#canary-workflow) to automatically publish test versions
|
|
229
|
+
of Canvas Kit. While these releases can be unstable, they are useful for external testing or
|
|
230
|
+
allowing teams to experiment with new features or fixes before a stable release is available. These
|
|
231
|
+
releases only run on `prerelease/minor` and `prerelease/major` branches.
|
|
232
|
+
|
|
233
|
+
#### Prerelease Minor Canaries
|
|
234
|
+
|
|
235
|
+
Canary releases on the `prerelease/minor` branch go out automatically once the pull request is
|
|
236
|
+
merged. The major version will be appended with `-next.{commit-count}`, where `commit-count` is the
|
|
237
|
+
number of commits since the last release tag. So for example, a V7 canary would look something like
|
|
238
|
+
this: `7.3.0-next.3`.
|
|
239
|
+
|
|
240
|
+
#### Prerelease Major Canaries
|
|
241
|
+
|
|
242
|
+
Canary releases on the `prerelease/major` branch go out automatically once the pull request is
|
|
243
|
+
merged. The major version will be appended with `-alpha.{build-number}-next.{commit-count}`, where
|
|
244
|
+
`build-number` is the GitHub build identifier, and `commit-count` is the number of commits since the
|
|
245
|
+
last release tag. So for example, a V8 canary would look something like this:
|
|
246
|
+
`8.0.0-alpha.127-next.4`.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@workday/canvas-kit-docs",
|
|
3
|
-
"version": "7.3.
|
|
3
|
+
"version": "7.3.3",
|
|
4
4
|
"description": "Documentation components of Canvas Kit components",
|
|
5
5
|
"author": "Workday, Inc. (https://www.workday.com)",
|
|
6
6
|
"license": "Apache-2.0",
|
|
@@ -42,7 +42,7 @@
|
|
|
42
42
|
],
|
|
43
43
|
"dependencies": {
|
|
44
44
|
"@storybook/csf": "0.0.1",
|
|
45
|
-
"@workday/canvas-kit-react": "^7.3.
|
|
45
|
+
"@workday/canvas-kit-react": "^7.3.3"
|
|
46
46
|
},
|
|
47
47
|
"devDependencies": {
|
|
48
48
|
"fs-extra": "^10.0.0",
|
|
@@ -50,5 +50,5 @@
|
|
|
50
50
|
"mkdirp": "^1.0.3",
|
|
51
51
|
"typescript": "4.1"
|
|
52
52
|
},
|
|
53
|
-
"gitHead": "
|
|
53
|
+
"gitHead": "4cc866b8d92cc55134caf83716359ddd5f7c8d67"
|
|
54
54
|
}
|