@brightspace-ui/intl - npm Package Compare versions

Comparing version 3.15.1 to 3.16.0

package.json

		{
		"name": "@brightspace-ui/intl",
		"version": "3.15.1",
		"version": "3.16.0",
		"description": "Internationalization APIs for number, date, time and file size formatting and parsing in D2L Brightspace.",
		@@ -42,3 +42,3 @@ "main": "lib/number.js",
		"@babel/eslint-parser": "^7",
		"@web/dev-server": "^0.3",
		"@web/dev-server": "^0.4",
		"chai": "^4",
		@@ -45,0 +45,0 @@ "concurrently": "^8",

README.md

		@@ -261,4 +261,8 @@ # intl

		## Running the test harness
		## Developing and Contributing

		After cloning the repo, run `npm install` to install dependencies.

		### Running the test harness

		Start a [@web/dev-server](https://modern-web.dev/docs/dev-server/overview/) that hosts the test harness:
		@@ -272,43 +276,10 @@

		## Contributing
		### Contributing

		Contributions are welcome, please submit a pull request!

		## 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.

@brightspace-ui/intl - npm Package Compare versions

Worsened metrics