@sayhiya/ui-components NPM

@sayhiya/ui-components

Component library for the SayHiya! UI.

Commits to this project should be structured as described in the Conventional Commits specification.

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

The commit contains the following structural elements, to communicate intent to the consumers of your library:

fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).
feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).
BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
types other than fix: and feat: are allowed, for example, build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.
footers other than BREAKING CHANGE: may be provided and follow a convention similar to git trailer format.

To maintain consistency and help others who rely on this code, when publishing new versions of this package please increment as follows:

Code Status	Stage	Rule	Example Version
First release	New product	Start with 1.0.0	1.0.0
Backward compatible bug fixes	Patch release	Increment the third digit	1.0.1
Backward compatible new features	Minor release	Increment the middle digit and reset last digit to zero	1.1.0
Changes that break backward compatibility	Major release	Increment the first digit and reset middle and last digits to zero	2.0.0

You shouldn’t have to worry about managing the version number manually. There is a npm command for bumping those numbers up:

$ npm version patch     # 0.1.0 -> 0.1.1
$ npm version minor     # 0.2.6 -> 0.3.0
$ npm version major     # 2.1.4 -> 3.0.0

For more information on semantic versioning please see: https://docs.npmjs.com/about-semantic-versioning

2 years ago