Release new crate

[badboy]

Care to release a new crate version? Btw, this commit by me was a rather bad decision. Best to use "0.5.1" now.

[nevdelap]

Hi badboy, I've not been developing recently but I'll try to get to it in the not too distant future.

[badboy]

Cool. If you need any other help just tell me. Happy to help out here.

[miketang84]

need it. thx.

[nevdelap]

Sorry everyone. I need someone to take over being maintainer of this. I am not actively doing anything rust related sadly because of being too busy in other work and non-IT related studies. Anyone want to take it over?

[badboy]

Sure, I can do it

[nevdelap]

Hi sorccu and badboy,

You have both said you can. Do you want to email me at xxxxx so we can make the transfer to whichever of you you think will most likely be able to maintain it long term?

Cheers.

PS: I'm GMT+10.

[badboy]

If @sorccu uses it in production, he's the right one to take over. I'll still be available with help

[sorccu]

@badboy, I've added you as a collaborator as well, you should have push access now. I will set up Travis later today. @nevdelap is adding me as an owner to the crate when he gets home, and we'll hopefully be able to release 0.2.0 soon.

[nevdelap]

Thanks Simo. I'm really chuft you're running with it. I should have offered to hand it over ages ago. Cheers!

[sorccu]

I'm trying to figure out a better way to update the docs and doc links, pretty much what @sfackler is doing with his crates. I'll release once that's done.

[badboy]

travis-cargo is pretty much the easiest way to handle all this. I can send a PR in the next days.

[sorccu]

Yeah, but it doesn't look like it gives you separate docs for each release. You only get master.

[badboy]

Ah, yeah. Then we need a slightly different approach.

[sfackler]

I use the highly advanced strategy of "do it all manually" :). The workflow is

$ git checkout -b release-v0.1.2
<update README.md, Cargo.toml, and src/lib.rs with the new version>
$ git add .
$ git commit -m "Release v0.1.2"
$ git checkout release
$ git merge --no-ff release-v0.1.2
$ git tag -a v0.1.2
$ git checkout master
$ git merge --no-ff release
$ git push --tags origin release master

# Now build docs
$ git checkout release
$ cargo doc --no-deps --features "all the features"
$ mv target/doc ..
$ git checkout gh-pages
$ mv ../doc doc/v0.1.2
$ git add doc
$ git commit -m "Release v0.1.2"
$ git push

# Assuming everything looks good, publish
$ git checkout release
$ cargo publish

It'd be pretty easy to automate but I haven't bothered.

[sorccu]

Thanks for the response!

I've kind of half-automated it right now. The main downside is that you have to publish the tag to make Travis build and publish the docs, which means that the links in GitHub will be pointing to docs that don't actually exist yet for a moment. Also, you have to remember to run script/update-doc-urls.sh after you bump the version number, but before tagging. In theory Travis could do all of this including cargo publish, but we'll see if I ever get to implementing that. Would be great for collaborators, though.

Anyway, I've just published 0.2.0, which means that we've finally got a version that works with the newest redis crate :)

[badboy]

I have ideas for that automatic cargo publish and everything. Stay tuned.

[sorccu]

That would be great! And sorry to keep spamming the same topic but one last note: @badboy I've also added you as an owner to the crate. So you should be able to publish the thing now, too. Currently you have to be a bit careful with the doc URLs when tagging a release as mentioned in my last post, so try to keep that in mind until we have something better. Also, when tagging, use the "v" prefix for the tag.