Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs(CONTRIBUTING): Improve the commit message documentation #1159

Merged
merged 3 commits into from
Oct 4, 2024

Conversation

mnonnenmacher
Copy link
Contributor

Add more details about the conventional commit types, the handling of breaking changes, and the versioning of the project.

Fixes #319.

Copy link
Contributor

@sschuberth sschuberth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we just had the discussion, should we also add that links to issues should be done in the commit, not in the PR?

CONTRIBUTING.md Show resolved Hide resolved
Add more details about the conventional commit types, the handling of
breaking changes, and the versioning of the project.

Fixes #319.

Signed-off-by: Martin Nonnenmacher <martin.nonnenmacher@bosch.com>
Signed-off-by: Martin Nonnenmacher <martin.nonnenmacher@bosch.com>
Signed-off-by: Martin Nonnenmacher <martin.nonnenmacher@bosch.com>
@mnonnenmacher mnonnenmacher added this pull request to the merge queue Oct 4, 2024
Merged via the queue into main with commit 345da3e Oct 4, 2024
14 checks passed
@mnonnenmacher mnonnenmacher deleted the improve-contributing branch October 4, 2024 18:04
For example, use "Add feature" instead of "Added feature".
#### Breaking changes

Breaking changes should be indicated by either adding a `BREAKING CHANGE:` section to the commit message body or by adding a `!` after the type, for example:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably should communicate what is considered a breaking change, so is the REST API only thing we consider for versioning. Also, if we plan to do API versioning (/api/v1/ etc.) what exactly is a breaking change if we strictly follow that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mmurto I have created a separate issue for this: #1172

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Document the commit convention of the project
3 participants