@brightspace-ui-labs/multi-select
Advanced tools
@brightspace-ui-labs/multi-select - npm Package Compare versions
Comparing version 6.3.4 to 6.4.0
@@ -35,3 +35,3 @@ { | ||
| "license": "Apache-2.0", | ||
| "version": "6.3.4", | ||
| "version": "6.4.0", | ||
| "devDependencies": { | ||
@@ -38,0 +38,0 @@ "@babel/core": "^7", |
@@ -173,39 +173,6 @@ # d2l-labs-multi-select | ||
| ## Versioning & Releasing | ||
| ### Versioning and Releasing | ||
| > TL;DR: Commits prefixed with `fix:` and `feat:` will trigger patch and minor releases when merged to `main`. Read on for more details... | ||
| This repo is configured to use `semantic-release`. Commits prefixed with `fix:` and `feat:` will trigger patch and minor releases when merged to `main`. | ||
| The [semantic-release GitHub Action](https://github.com/BrightspaceUI/actions/tree/main/semantic-release) is called from the `release.yml` GitHub Action workflow to handle version changes and releasing. | ||
| ### Version Changes | ||
| All version changes should obey [semantic versioning](https://semver.org/) rules: | ||
| 1. **MAJOR** version when you make incompatible API changes, | ||
| 2. **MINOR** version when you add functionality in a backwards compatible manner, and | ||
| 3. **PATCH** version when you make backwards compatible bug fixes. | ||
| 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: | ||
| * Commits which are prefixed with `fix:` or `perf:` will trigger a `patch` release. Example: `fix: validate input before using` | ||
| * Commits which are prefixed with `feat:` will trigger a `minor` release. Example: `feat: add toggle() method` | ||
| * To trigger a MAJOR release, include `BREAKING CHANGE:` with a space or two newlines in the footer of the commit message | ||
| * Other suggested prefixes which will **NOT** trigger a release: `build:`, `ci:`, `docs:`, `style:`, `refactor:` and `test:`. Example: `docs: adding README for new component` | ||
| 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`. | ||
| ### Releases | ||
| When a release is triggered, it will: | ||
| * Update the version in `package.json` | ||
| * Tag the commit | ||
| * Create a GitHub release (including release notes) | ||
| * Deploy a new package to NPM | ||
| ### Releasing from Maintenance Branches | ||
| 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). | ||
| Maintenance branch names should be of the form: `+([0-9])?(.{+([0-9]),x}).x`. | ||
| Regular expressions are complicated, but this essentially means branch names should look like: | ||
| * `1.15.x` for patch releases on top of the `1.15` release (after version `1.16` exists) | ||
| * `2.x` for feature releases on top of the `2` release (after version `3` exists) | ||
| To learn how to create major releases and release from maintenance branches, refer to the [semantic-release GitHub Action](https://github.com/BrightspaceUI/actions/tree/main/semantic-release) documentation. |
New alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Fixed alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Worsened metrics
- Total package byte prevSize
- decreased by-3.03%
69351
- Number of lines in readme file
- decreased by-15.64%
178
No dependency changes