Rust-rocksdb: Release 0.11.0

Created on 5 Dec 2018  ·  31Comments  ·  Source: rust-rocksdb/rust-rocksdb

Over 60 commits and a number of features have accumulated since the 0.10.1 release. I recommend we publish a new release, 0.11.0.

Most helpful comment

done!

On Mon, Dec 31, 2018 at 2:45 PM Jordan Terrell notifications@github.com
wrote:

@spacejam https://github.com/spacejam Sweet. Can you do the same for
librocksdb-sys? We need to snap a new version of that before we can
release rocksdb.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-rocksdb/rust-rocksdb/issues/233#issuecomment-450647477,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABb40P07sDUlodN6GAroXi3fEOe7gR2zks5u-hTngaJpZM4ZDJPL
.

All 31 comments

@spacejam Are there specific directions on the process to publish a release?

Great work everyone!!! It's been really cool seeing you folks making great progress :)

I would actually like to suggest that we release a 1.0.0 to celebrate this project growing up :)

But I leave this decision to you! I've written up the below guide assuming 0.11.0. Let me know if this would be useful in MAINTAINERSHIP.md and I'll open a PR!

If you are feeling uncertain and want to be careful:

  1. in a fresh branch, bump the Cargo.toml metadata to 0.11.0-pre.0
  2. remove your Cargo.lock file. This will cause any nested dependencies to be updated, and this is the cause of breakage sometimes when a crate is able to be built and published locally but can't be used by newcomers because an incorrect patch version somewhere broke something.
  3. issue cargo publish --allow-dirty from the root directory (never use --allow-dirty for a non-pre release, we're basically running this as a pre-release check though so it's OK)
  4. build a fresh cargo clean'd project somewhere with no cache that uses on the newly published version, and make sure it builds and runs with the new version specified. If it already has a Cargo.lock file, remove it!
  5. if there were any issues either publishing or using the published version, use cargo yank --vers 0.11.0-pre.0, then address those issues. goto 1 until this works without any issues.

when you have confidence in the quality of the release:

  1. in a new fresh branch, roll the changelog to 0.11.0 and set the Cargo.toml version to 0.11.0
  2. cargo clean then rm Cargo.lock to fetch and use completely updated deps before publishing
  3. run cargo publish
  4. create a new dependency project that relies on the newly published version
  5. use the github "Draft a new release" function from the releases page, where nicely formatted release notes can be placed (basically just copy + pasted from the changelog for 0.11.0).
  6. all done :)

Each of the maintainers have publishing permissions for crates.io, and generally I would recommend that multiple people over time exercise this power so that it feels comfortable.

This is generally the aspect of running the project where the build times are really annoying x_x But the steps are not particularly energy intensive so you can do most of it while watching a movie or doing something more productive.

If you'd like me to be available for a chat on gitter etc... while one of you does this, I'm more than happy to find a time in the next few days where we're both available.

@iSynaptic would you like to perform the release?

@spacejam Sure, I'll perform the release.

I don't want to speak for everyone, but I feel there are some more things we can do to mature the library a bit more before we publish a 1.0.0 release. The issue log has a lot of suggestions. I'd like to get the open issue count down a bit more.

@aleksuss If you are 👍 on the release, I'll get started.

@iSynaptic Let's do this 😄

@spacejam Looks like we need to publish a new version of librocksdb-sys, perhaps 5.14.3? Same steps, but from the librocksdb-sys path, first?

@spacejam Doesn't look like crate-publishers has been added as an owner of librocksdb-sys on crates.io -- can you add that?

@iSynaptic sorry for that! done!

yeah, librocksdb-sys just tracks the underlying rocksdb version, and we've been lucky not to need to yank a release without being able to roll forward a little more

@spacejam Okay, next hurdle. I'm getting a permissions issue with cargo publish:

error: api errors: this crate exists but you don't seem to be an owner. If you believe this is a mistake, perhaps you need to accept an invitation to be an owner before publishing.

It appears there are some more hurdles to get this all working with Github Teams. Looks like crate-publishers doesn't have permissions to access the organization settings, so I'm not able to authorize crates.io to access organization/team info on GitHub.

@iSynaptic sorry for a stupid question, but you've run cargo login your_token, haven't you ?

@iSynaptic sorry for a stupid question, but you've run cargo login your_token, haven't you ?

lol. Not a stupid question. Yes, I did -- and I generated the token this morning after Tyler setup the permission on librocksdb-sys.

@iSynaptic I just hit the button that blanket-removed all restrictions for github 3rd party apps, but I'm not sure if that will change things or not :/ Could you try again now? If this still isn't working I'll try to get in touch with the crates.io folks to figure out more info.

@spacejam Same issue, even after creating a new login token. 😞

@spacejam What do you think about to add members of crate-publishers group directly to owners of crates librocksdb-sys and rocksdb ? Definitively we've got stuck with the issue of group access.

@spacejam @aleksuss That probably would be the fastest path to resolution. I get the sense that assigning GitHub teams to crate ownership isn't a common or well supported scenario.

sorry for the huge delay on this, I've added @aleksuss and @iSynaptic as owners for now!

@spacejam Sweet. Can you do the same for librocksdb-sys? We need to snap a new version of that before we can release rocksdb.

done!

On Mon, Dec 31, 2018 at 2:45 PM Jordan Terrell notifications@github.com
wrote:

@spacejam https://github.com/spacejam Sweet. Can you do the same for
librocksdb-sys? We need to snap a new version of that before we can
release rocksdb.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-rocksdb/rust-rocksdb/issues/233#issuecomment-450647477,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABb40P07sDUlodN6GAroXi3fEOe7gR2zks5u-hTngaJpZM4ZDJPL
.

I'll try snapping a release later today. Did we want to try to get #238 into this release?

@iSynaptic I don't see reasons why don't include it.

Didn't get to the release on Saturday like I had planned. Starting on it now...

librocksdb-sys 5.14.3 has been published. Working on rocksdb 0.11.0-pre.0 right now.

rocksdb 0.11.0-pre.0 has been published. I will do some testing -- I welcome some testing from others. Once I get a 👍, I will publish final version.

@iSynaptic I've tested your pre-release in my project. I haven't seen any problems. Looks good. But If you think it is possible it would be nice to have https://github.com/rust-rocksdb/rust-rocksdb/pull/241 in 0.11.0. Thanks.

@aleksuss Thanks. Would you be okay with doing a 0.11.1 release shortly after this one with #241 included? This release has been held up for quite a while and I would like to get it released.

@vitvakatu @spacejam Any feedback on the quality of the pre-release? (no problem if you haven't been able to look at it)

@iSynaptic Ok. No problem.

I've completed my testing. I'm ready to release.

@aleksuss @vitvakatu @spacejam I'm going to release 0.11.0. now. I'll start by yanking the 0.11.0-pre.0 release. Once I publish the release, I'll push the changelog update, tag the commit, and create a GitHub release.

Done!

Thanks to @spacejam, @aleksuss, @vitvakatu, @ekmartin, @s-panferov, @Tpt, @Elzor, and @romanz for making this release happen!

Was this page helpful?
0 / 5 - 0 ratings