fluencelabs/rust-libp2p
1
0
Fork 0
mirror of https://github.com/fluencelabs/rust-libp2p synced 2025-05-29 18:51:22 +00:00
Code Issues Projects Releases Wiki Activity

docs: update policy on breaking changes and changelog entry format

Browse Source 
Pull-Request: #3615.
This commit is contained in:
Thomas Eizinger 2023-03-22 15:21:43 +01:00 committed by GitHub
parent 0e468655a4
commit 3411b2697c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 25 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
docs/release.md
View File

@ -5,15 +5,30 @@ documentation will refer to `X.Y.Z` as _major_, _minor_ and _patch_ version.
## Development between releases ## Development between releases
- Every substantial pull request should add an entry to the `[unreleased]` ### Prefer non-breaking changes
section of the corresponding crate `CHANGELOG.md` file. See
[#1698](https://github.com/libp2p/rust-libp2p/pull/1698/files) as an example.
In case there is no `[unreleased]` section yet, create one with an increased We strive to minimize breaking changes for our users.
major, minor or patch version depending on your change. Update the version in PRs with breaking changes are not merged immediately but collected in a milestone.
the crate's `Cargo.toml`. In addition update the corresponding entry of the For example: https://github.com/libp2p/rust-libp2p/milestone/6.
crate in the root level `Cargo.toml` and add an entry in the root level
`CHANGELOG.md`. Non-breaking changes are typically merged very quickly and often released as patch-releases soon after.
### Make changelog entries
Every crate that we publish on `crates.io` has a `CHANGELOG.md` file.
Substantial PRs should add an entry to each crate they modify.
The next unreleased version is tagged with ` - unreleased`, for example: `0.17.0 - unreleased`.
In case there isn't a version with an ` - unreleased` postfix yet, add one for the next version.
The next version number depends on the impact of your change (breaking vs non-breaking, see above).
If you are making a non-breaking change, please also bump the version number in the `Cargo.toml` manifest.
In case another crate _depends_ on the new features or APIs that you are adding, you may need to bump the dependency declaration in that `Cargo.toml` file as well.
Don't worry if you don't get this one right, we will flag it in the PR if necessary :)
For breaking changes, a changelog entry itself is sufficient.
Bumping the version in the `Cargo.toml` file would lead to many merge conflicts once we decide to merge them.
Hence, we are going to bump those versions once we work through the milestone that collects the breaking changes.
## Releasing one or more crates ## Releasing one or more crates
@ -23,9 +38,8 @@ documentation will refer to `X.Y.Z` as _major_, _minor_ and _patch_ version.
### Steps ### Steps
1. Remove the `[unreleased]` tag for each crate to be released in the respective 1. Remove the ` - unreleased` tag for each crate to be released in the respective `CHANGELOG.md`.
`CHANGELOG.md`. Create a pull request with the changes against the Create a pull request with the changes against the rust-libp2p `master` branch.
rust-libp2p `master` branch.
2. Once merged, run the two commands below on the (squash-) merged commit on the `master` branch. 2. Once merged, run the two commands below on the (squash-) merged commit on the `master` branch.