Semantic Versioning Guide

See Conventional Commits

The release.yml, checkPullRequest.yml and testRelease.yml Github Action Workflows in this repo are designed to act on the commit comment rules that follow.

As an open-source maintainer, squash feature branches onto master and write a standardized commit message while doing so. The commit message should be structured as follows:

<type>: This represents the type of change made in the commit. Common types include feat (for a new feature), fix (for a bug fix), chore (for routine tasks like updating dependencies), docs (for documentation changes), style (for code style changes), refactor (for refactoring existing code), test (for adding or updating tests), and perf (for performance improvements).

[optional scope]: This is an optional part that provides additional contextual information, like the part of the codebase the commit modifies.

<description>: This is a brief description of the changes the commit makes.

[optional body]: This is an optional part where you can provide a more detailed explanation of the changes.

[optional footer(s)]: This is also optional and is often used to reference issue tracker IDs.

Commit Message format

feat: A new feature
fix: A bug fix
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
perf: A code change that improves performance
test: Adding missing or correcting existing tests
chore: Changes to the build process or auxiliary tools and libraries such as documentation generation

Example

git commit -m "docs: add an example of a good commit message"

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!