Make a release

Question

Make a release

little-dude opened this issue 3 years ago · comments

little-dude commented 3 years ago

Just to keep track of the PRs I want to merge for this release:

Tim Zhang commented 3 years ago

@cathay4t

Tim Zhang · Answer 1 · Wed Feb 24 2021 20:30:33 GMT+0800 (China Standard Time)

@little-dude How is this going?

Michael Richardson · Answer 2 · Mon Jun 28 2021 03:45:09 GMT+0800 (China Standard Time)

Hi, what's on crates.io does not use tokio-util 0.6, see: https://crates.io/crates/netlink-proto/0.6.0/dependencies which shows tokio-util 0.2.0, which sucks in tokio 0.2, which leads to disaster.
Maybe the wrong code was released?

Yuki Okushi · Answer 3 · Mon Jun 28 2021 06:05:58 GMT+0800 (China Standard Time)

@mcr Note that #147 hasn't been released yet. It should happen once we're ready, i.e., the TODOs are done.

little-dude · Answer 4 · Mon Jun 28 2021 15:29:35 GMT+0800 (China Standard Time)

I don't think we really need to wait for #146 to make a release tbh.

Yuki Okushi · Answer 5 · Mon Jun 28 2021 16:27:06 GMT+0800 (China Standard Time)

I agree but the failure can be fixed easily. I've pushed a commit with a tweak, I'll merge it once CI becomes green.

Yuki Okushi · Answer 6 · Mon Jun 28 2021 16:33:09 GMT+0800 (China Standard Time)

@little-dude Do you have some notes about the release process, e.g. in what order should we release the crates?

Yuki Okushi · Answer 7 · Mon Jun 28 2021 16:41:42 GMT+0800 (China Standard Time)

And #150 may be worth including in the next release.

little-dude · Answer 8 · Tue Jun 29 2021 03:52:53 GMT+0800 (China Standard Time)

@little-dude Do you have some notes about the release process, e.g. in what order should we release the crates?

No I haven't. Let me do this one and take some notes. It's not so easy because crates need to be published in a certain order due to dependencies.

little-dude · Answer 9 · Tue Jun 29 2021 04:35:25 GMT+0800 (China Standard Time)

Working on the release but I'm going to bed. I'll finish first thing tomorrow morning and publish the notes.

little-dude · Answer 10 · Tue Jun 29 2021 16:11:26 GMT+0800 (China Standard Time)

Done: #171

little-dude · Answer 11 · Tue Jun 29 2021 16:11:38 GMT+0800 (China Standard Time)

Here are some notes about releases :)

First, I distinguish three groups of crates:

netlink-packet-* crates
netlink-sys
netlink-proto, audit and rtnetlink, which depend on the the two other groups

I usually start by bumping the versions of the first group of crates,
then netlink-sys, and then the last group of crates.

For the record here are the dependency tree for each group.

netlink-packet-utils v0.4.0

netlink-packet-core v0.2.4
└── netlink-packet-utils v0.4.0
[dev-dependencies]
└── netlink-packet-route v0.7.0
    ├── netlink-packet-core v0.2.4
    └── netlink-packet-utils v0.4.0

netlink-packet-route v0.7.0
├── netlink-packet-core v0.2.4
│   └── netlink-packet-utils v0.4.0
└── netlink-packet-utils v0.4.0
[dev-dependencies]
└── netlink-sys v0.6.0

netlink-packet-audit v0.2.2
├── netlink-packet-core v0.2.4
│   └── netlink-packet-utils v0.4.0
└── netlink-packet-utils v0.4.0

netlink-packet-sock-diag v0.1.0
├── netlink-packet-core v0.2.4
│   └── netlink-packet-utils v0.4.0
└── netlink-packet-utils v0.4.0
[dev-dependencies]
└── netlink-sys v0.6.0

Then netlink-sys:

netlink-sys v0.6.0
[dev-dependencies]
└── netlink-packet-audit v0.2.2
    ├── netlink-packet-core v0.2.4
    │   └── netlink-packet-utils v0.4.0
    └── netlink-packet-utils v0.4.0

Finally, netlink-proto, audit and rtnetlink, which use both the
netlink-packet-* crates and netlink-sys:

netlink-proto v0.6.0
├── netlink-packet-core v0.2.4
│   └── netlink-packet-utils v0.4.0
└── netlink-sys v0.6.0
[dev-dependencies]
├── netlink-packet-audit v0.2.2
└── netlink-packet-route v0.7.0

audit v0.3.1
├── netlink-packet-audit v0.2.2
│   ├── netlink-packet-core v0.2.4
│   │   └── netlink-packet-utils v0.4.0
│   └── netlink-packet-utils v0.4.0
└── netlink-proto v0.6.0
    ├── netlink-packet-core v0.2.4
    └── netlink-sys v0.6.0

rtnetlink v0.7.0
├── netlink-packet-route v0.7.0
│   ├── netlink-packet-core v0.2.4
│   │   └── netlink-packet-utils v0.4.0
│   └── netlink-packet-utils v0.4.0
└── netlink-proto v0.6.0
    ├── netlink-packet-core v0.2.4
    └── netlink-sys v0.6.0

For each crate, I look at when was the last time the version was
changed. For instance for rtnetlink:

$ git blame rtnetlink/Cargo.toml  | grep "version = "
88dde610 rtnetlink/Cargo.toml   (little-dude    2021-01-20 20:09:23 +0100  3) version = "0.7.0"
2f721807 rtnetlink/Cargo.toml   (Stefan Bühler  2021-06-06 14:20:15 +0200 26) netlink-proto = { default-features = false, version = "0.6" }
83da33e2 rtnetlink/Cargo.toml   (gabrik         2021-01-22 16:22:16 +0100 29) tokio = { version = "1.0.1", features = ["rt"], optional = true}
83da33e2 rtnetlink/Cargo.toml   (gabrik         2021-01-22 16:22:16 +0100 30) async-std = { version = "1.9.0", features = ["unstable"], optional = true}
ef3a79a8 rtnetlink/Cargo.toml   (Tim Zhang      2021-01-15 19:31:38 +0800 35) tokio = { version = "1.0.1", features = ["macros", "rt", "rt-multi-thread"] }
83da33e2 rtnetlink/Cargo.toml   (gabrik         2021-01-22 16:22:16 +0100 36) async-std = { version = "1.9.0", features = ["attributes"]}

$ git log  --oneline 88dde610.. rtnetlink/
2f72180 Cargo.toml: move path specs to workspace [patch.crates-io] section
1e8bc53 CI: Fix rtnetlink example
cae6e09 Merge pull request #97 from SkamDart/SkamDart/ip-monitor
35b6cb9 use `unwrap()` instead of `.is_ok()` so that the error is printed
2f0877a (origin/release) rustfmt, clippy
5c39136 Merge pull request #130 from benjumanji/wireguard-type
af1ee71 Merge pull request #137 from little-dude/rtnetlink-macros
83da33e added features and examples to rtnetlink
079b5f3 (origin/rtnetlink-macros) rtnetlink: use macros in response handling
b681f35 Add basic test for bringing up interface
5201dcd ip monitor clone

Based on the changes, I decide whether I bump the patch or minor
version. For crates that like rtnetlink, I usually just bump the
minor version. For netlink-packet-* and netlink-sys, I try to bump
it only if really necessary, because bumping it means bumping all the
crates that depend on it.

Once I have bumped all the version locally, I push to a release
branch to have CI running. If CI passes, I just go with cargo publish, again starting from the netlink-packet-* and netlink-sys
crates. --dry-run is nice but it doesn't really work. For instance
if netlink-packet-utils is bumped from 0.x to 0.x+1, then cargo publish --dry-run will not work for netlink-packet-core, because
the crate depends on netlink-packet-utils 0.x+1, which hasn't be
published yet.

Summary

bump the versions in the Cargo.toml using git blame and git log,
starting from the netlink-packet-* and netlink-sys crates
check that cargo test still works once your done
cargo publish

This process is tedious and error prone so I'm open to idea and
re-organizations to make this easier. I've already messed up the
releases a couple times, but in that case, I just bump the version
again and re-release.

Yuki Okushi · Answer 12 · Tue Jun 29 2021 17:50:48 GMT+0800 (China Standard Time)

Thanks, @little-dude for the write-up! One suggestion is to have CHANGELOG.md on each crate, determine if a PR is a semver-patch, minor, or major change, then add an entry there on reviewing so that we don't have to check git log but just to see the changelog (or, "major or not" is enough here since the crates' versions here are all 0.y.z).
This would make the review process longer sometimes but we cannot miss a breaking change when releasing. And the changelog is helpful for users as well when checking a new release.
Anyway, I'm going to add a RELEASE_PROCESS.md to the root with your notes so that we don't forget the way :)