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
**Note:** Iframe Brightspace pages that contain a navbar and/or minbar (such as quizzes and surveys) will have these removed in the ResizingIframe.
43
43
44
-
### Bump version ###
44
+
##Versioning & Releasing
45
45
46
-
```BASH
47
-
$ # npm help 1 version
48
-
$ # npm help 7 semver
49
-
$ npm version [major|minor|patch|premajor|preminor|prepatch|prerelease] -m "chore(version) bump %s"
50
-
$ git push upstream master --tags
51
-
```
46
+
> TL;DR: Commits prefixed with `fix:` and `feat:` will trigger patch and minor releases when merged to `main`. Read on for more details...
47
+
The [sematic-release GitHub Action](https://github.com/BrightspaceUI/actions/tree/master/semantic-release) is called from the `release.yml` GitHub Action workflow to handle version changes and releasing.
48
+
49
+
### Version Changes
50
+
51
+
All version changes should obey [semantic versioning](https://semver.org/) rules:
52
+
1.**MAJOR** version when you make incompatible API changes,
53
+
2.**MINOR** version when you add functionality in a backwards compatible manner, and
54
+
3.**PATCH** version when you make backwards compatible bug fixes.
55
+
56
+
The next version number will be determined from the commit messages since the previous release. Our semantic-release configuration uses the [Angular convention](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular) when analyzing commits:
57
+
* Commits which are prefixed with `fix:` or `perf:` will trigger a `patch` release. Example: `fix: validate input before using`
58
+
* Commits which are prefixed with `feat:` will trigger a `minor` release. Example: `feat: add toggle() method`
59
+
* To trigger a MAJOR release, include `BREAKING CHANGE:` with a space or two newlines in the footer of the commit message
60
+
* Other suggested prefixes which will **NOT** trigger a release: `build:`, `ci:`, `docs:`, `style:`, `refactor:` and `test:`. Example: `docs: adding README for new component`
61
+
62
+
To revert a change, add the `revert:` prefix to the original commit message. This will cause the reverted change to be omitted from the release notes. Example: `revert: fix: validate input before using`.
63
+
64
+
### Releases
65
+
66
+
When a release is triggered, it will:
67
+
* Update the version in `package.json`
68
+
* Tag the commit
69
+
* Create a GitHub release (including release notes)
70
+
* Deploy a new package to NPM
71
+
72
+
### Releasing from Maintenance Branches
73
+
74
+
Occasionally you'll want to backport a feature or bug fix to an older release. `semantic-release` refers to these as [maintenance branches](https://semantic-release.gitbook.io/semantic-release/usage/workflow-configuration#maintenance-branches).
75
+
76
+
Maintenance branch names should be of the form: `+([0-9])?(.{+([0-9]),x}).x`.
77
+
78
+
Regular expressions are complicated, but this essentially means branch names should look like:
79
+
*`1.15.x` for patch releases on top of the `1.15` release (after version `1.16` exists)
80
+
*`2.x` for feature releases on top of the `2` release (after version `3` exists)
0 commit comments