Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 15 additions & 22 deletions docs/release.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,43 +17,34 @@ Non-breaking changes are typically merged very quickly and often released as pat

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`.
We have a CI check[^1] that enforces adding a changelog entry if you modify code in a particular crate.
In case the current version is already released (we also check that in CI), you'll have to add a new header at the top.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This in particular makes it a bit harder to contribute. Previously it was clear from changelog alone if it is released or not. Now I guess I'll need to check crates.io as well to see if I need to add new section or not.

This whole changelog management process seems quite heavy to be honest.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I recognize that it is not ideal but I'd assume that most PRs go through at least one review cycle and multiple CI runs. Thus, a viable approach for contributors should be to just add to the top-most changelog entry and see if CI accepts that or not.

In fact, other than for experienced contributors like yourself, I'd expect this to be the default.

This whole changelog management process seems quite heavy to be honest.

I am definitely open to other ideas. So far, I've mostly tried to optimise for correctness and ease of maintainability, hence the high degree of automation here.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

If checks are smart enough to verify that already released entry is updated with more changes I think it is good, can't imagine how much debugging it took to make it work 😮

Copy link
Copy Markdown
Contributor Author

@thomaseizinger thomaseizinger Nov 20, 2023

Choose a reason for hiding this comment

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

If checks are smart enough to verify that already released entry is updated with more changes I think it is good, can't imagine how much debugging it took to make it work 😮

Essentially, we check top_most_version_in_changelog_is_unreleased && changelog_has_been_modified. There is a corner-case where the top-most entry is unreleased and you modify an entry further down below. I don't really see why anybody would do that so I didn't bother codifying that (plus it is easy to catch during the review) :)

It took several attempts at making the checks robust but they've been working quite well recently :)

For example, the top-listed version might be `0.17.3` but it is already released.
In that case, add a new heading `## 0.17.4` with your changelog entry in case it is a non-breaking change.

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 of the respective crate
- in the `[workspace.dependencies]` section of the workspace `Cargo.toml` manifest

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.
The version in the crate's `Cargo.toml` and the top-most version in the `CHANGELOG.md` file always have to be in sync.
Additionally, we also enforce that all crates always depend on the latest version of other workspace-crates through workspace inheritance.
As a consequence, you'll also have to bump the version in `[workspace.dependencies]` in the workspace `Cargo.toml` manifest.

## Releasing one or more crates

The above changelog-management strategy means `master` is always in a state where we can make a release.

### Prerequisites

- [cargo release](https://github.com/crate-ci/cargo-release/)

### Steps

1. Remove the ` - unreleased` tag for each crate to be released in the respective `CHANGELOG.md`.
Create a pull request with the changes against the rust-libp2p `master` branch.

2. Once merged, run the two commands below on the (squash-) merged commit on the `master` branch.
1. Run the two commands below on the (squash-) merged commit on the `master` branch.

1. `cargo release publish --execute`

2. `cargo release tag --sign-tag --execute`

3. Confirm that `cargo release` tagged the commit correctly via `git push
$YOUR_ORIGIN --tag --dry-run` and then push the new tags via `git push
$YOUR_ORIGIN --tag`. Make sure not to push unrelated git tags.

Note that dropping the `--no-push` flag on `cargo release` might as well do
the trick.
2. Confirm that `cargo release` tagged the commit correctly via `git push $YOUR_ORIGIN --tag --dry-run`
Push the new tags via `git push $YOUR_ORIGIN --tag`.
Make sure not to push unrelated git tags.

## Patch release

Expand All @@ -77,3 +68,5 @@ To avoid accidental breaking changes for our users, we employ the following conv
Example: `0.1.0-alpha` to `0.2.0-alpha`.
- For a non-breaking change in a crate with an alpha release, bump or append number to the "alpha" tag.
Example: `0.1.0-alpha` to `0.1.0-alpha.1`.

[^1]: See [ci.yml](../.github/workflows/ci.yml) and look for "Ensure manifest and CHANGELOG are properly updated".
2 changes: 1 addition & 1 deletion protocols/gossipsub/CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
## 0.46.1 - unreleased
## 0.46.1

- Deprecate `Rpc` in preparation for removing it from the public API because it is an internal type.
See [PR 4833](https://github.com/libp2p/rust-libp2p/pull/4833).
Expand Down
2 changes: 1 addition & 1 deletion protocols/identify/CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
## 0.44.1 - unreleased
## 0.44.1

- Ensure `Multiaddr` handled and returned by `Behaviour` are `/p2p` terminated.
See [PR 4596](https://github.com/libp2p/rust-libp2p/pull/4596).
Expand Down
2 changes: 1 addition & 1 deletion protocols/kad/CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
## 0.45.2 - unreleased
## 0.45.2

- Ensure `Multiaddr` handled and returned by `Behaviour` are `/p2p` terminated.
See [PR 4596](https://github.com/libp2p/rust-libp2p/pull/4596).
Expand Down
2 changes: 1 addition & 1 deletion protocols/mdns/CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
## 0.45.1 - unreleased
## 0.45.1

- Ensure `Multiaddr` handled and returned by `Behaviour` are `/p2p` terminated.
See [PR 4596](https://github.com/libp2p/rust-libp2p/pull/4596).
Expand Down
2 changes: 1 addition & 1 deletion scripts/add-changelog-header.sh
Original file line number Diff line number Diff line change
Expand Up @@ -7,4 +7,4 @@ if [[ $header == $prefix* ]]; then
exit
fi

sed -i "1i ## ${NEW_VERSION} - unreleased\n\n" "$CRATE_ROOT/CHANGELOG.md"
sed -i "1i ## ${NEW_VERSION}\n\n" "$CRATE_ROOT/CHANGELOG.md"