Continuous delivery

All pull requests merged into the main branch should be done so using a squash and merge commit. If you're the contributor who approves the squash and merge, be sure to author a commit message using these these guidelines. The merge message will be parsed in order to determine the next semantic version.

Each squash and merge commit message will represent one change in the release notes.   (optional scope):

These types will bump the semantic version

• fix: Patches a bug in your codebase (this correlates with PATCH in semantic versioning).
• feat: Introduces a new feature to the codebase (this correlates with MINOR in semantic versioning).
• perf:: A code change that improves performance (this correlates with PATCH in semantic versioning).
• !: Appending an ! 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.

Note: If the type is feat, fix or perf, the semantic version will change. BREAKING CHANGES denoted by any type followed by ! will result in a major version bump.

These types will not change the semantic version, but will be included in the release notes of the next semantic version change.

• chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• refactor: A code change that neither fixes a bug nor adds a feature
• test: Adding missing or correcting existing tests

A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g., feat(parser): add ability to parse arrays. The scope could be anything specifying place of the commit change. For example tools, adapters, Linechart, Models, etc...

Contains succinct description of the change:

• use the imperative, present tense: "change" not "changed" nor "changes"
• don't capitalize first letter
• no dot (.) at the end

All releases should be triggered by opening a pull request from main into release. Releases should use traditional merge commits (not squash and merge). This will ensure the semantic version number for the release is automatically determined based on the previously squashed commits merged into main. Note: release must be merged back into main after each release PR, this will reset the beta semantic version.

Each time a pull request is opened targeting main, actions are automatically run to verify the build, linting, and tests pass.

Commits pushed to the main and release branches will trigger semantic versioning and NPM package release. Use the merge guidelines above to control the package versioning.

All branches pushed to this repository will automatically generate live Storybook URLs using the following format https://--601c6b2fcd385c002100f14c.chromatic.com