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.

Sign up for GitHub

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

Jump to bottom

Update CONTRIBUTING.md #671

Merged
merged 1 commit into from Sep 2, 2022
Merged

Update CONTRIBUTING.md #671

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
6 changes: 2 additions & 4 deletions CONTRIBUTING.md
View file
Open in desktop
Expand Up @@ -4,9 +4,7 @@ parity-common welcomes contribution from everyone in the form of suggestions, bu
reports, pull requests, and feedback. This document gives some guidance if you
are thinking of helping us.

Please reach out here in a GitHub issue or in the parity channel on [gitter] if we can do anything to help you contribute.

[gitter]: https://gitter.im/paritytech/parity
Please reach out here in a GitHub issue if we can do anything to help you contribute.

## Submitting bug reports and feature requests

Expand All @@ -24,7 +22,7 @@ solve with the feature, any ideas for how parity-common could support solving th

As many crates in the rust ecosystem, all crates in parity-common follow [semantic versioning]. This means bumping PATCH version on bug fixes that don't break backwards compatibility, MINOR version on new features and MAJOR version otherwise (MAJOR.MINOR.PATCH). Versions < 1.0 are considered to have the format 0.MAJOR.MINOR, which means bumping MINOR version for all non-breaking changes.

If you bump a dependency that is publicly exposed in a crate's API (e.g. `pub use dependency;` or `pub field: dependency::Dependency`) and the version transition for the dependency was semver-breaking, then it is considered to be a breaking change for the consuming crate as well. To put it simply, if your change could cause a compilation error in user's code, it is a breaking change.
For checking whether a change is SemVer-breaking, please refer to https://doc.rust-lang.org/cargo/reference/semver.html.

Bumping versions should be done in a separate from regular code changes PR.

Expand Down