@brightspace-hmc/siren-sdk
This contains tools written in ES6 to help develop and use Siren entities.
Quick start
Options for getting started:
- Download the latest release.
- Clone the repo:
git clone https://github.com/BrightspaceHypermediaComponents/siren-sdk.git
. - Install with npm:
npm install @brightspace-hmc/siren-sdk
.
Versioning & Releasing
TL;DR: Commits prefixed with fix:
and feat:
will trigger patch and minor releases when merged to main
. Read on for more details...
The semantic-release GitHub Action is called from the release.yml
GitHub Action workflow to handle version changes and releasing.
Version Changes
All version changes should obey semantic versioning rules:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards compatible manner, and
- 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 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.
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)