0.13.0 release

[stearnsc]

We've been sitting on 0.13.0-dev for quite some time, and the current released version has some Bad™ issues that should be resolved (e.g. #179). I've recently taken over publishing rights of this crate from @kestred and am collaborating w/ @arlyon and @seanpianka to return this crate to some semblance of maintenance.

With that context, I'd like to discuss what, if anything, remains to be done before we're comfortable w/ releasing 0.13.0. We're currently pinning a specific recent commit of this library internally in production, which speaks to some semblance of stability at least around the features we're using (which are pretty simple). @arlyon / @seanpianka / @kestred are any of you aware of anything Important™ we should complete before simply releasing 0.13.0? I don't know if there was originally some plan around releases of this crate vs stripe API versions, but my instinct is even if so, we shouldn't let perfect be the enemy of done.

[seanpianka]

In terms of important fixes that should go into a next release, I can think of a few that should be considered:

• Support for idempotent requests. #129 - Re-enable connection pooling by implementing idempotency keys
• Async error when using with actix #153 - async issues with actix - we can determine if a fix is needed or if it's just a documentation issue
• Get rid of the smol_str dependency #144 - questions on smol_str dependency - unless there's a plan to remove this, we should close this and add 1.51-53 as the minimum version of Rust to use this crate.
• Properly support the 2020 api. #133 - I don't know the extent to which the "2020" version of the API is used, as compared to whichever version this crate currently implements. Any ideas on the effort involved to support this version, and would it break compatibility from the current version?

Thanks for setting this up! I'm looking forward to active maintenance of the crate, in hope that #96 can be iterated upon. The binary size is quite large. 😅

[arlyon]

I think we need to sort out CI as well. Travis is failing on most PRs (example) because tests aren't building properly. We need to sort out a matrix for each backend, and make sure tests only run on the backend they are written for. We also spin up and take down a docker image for mock stripe which can be simplified. Github actions supports service images which can help this immensely and should make things more consistent. Build time can be brought down by using caching as well.

For example (from the fork I was working on): https://github.com/arlyon/async-stripe/blob/master/.github/workflows/async-stripe.yml

Happy to upstream if we are okay moving from travis to GH actions.

[seanpianka]

@arlyon I am okay with moving from Travis to GH actions, and I think an effort to upstream all of the features and enhancements in async-stripe would be the most beneficial. Then with those improvements, we can release a a new 0.13 version for stripe-rs.

[maxall41]

Any updates on this?

[stearnsc]

Good question. @seanpianka @arlyon since we haven't been proactive in moving forward on this list, I think I'd advocate for determining the bare minimum required to make a release, and doing so. Unfortunately, since I wasn't involved in the initial development of this crate, I don't have a strong intuition about what's "safe" or not. That said, we've internally depending on master in production for quite a while, so we potentially could just release as-is.

Thoughts?

[arlyon]

There are a number of PRs that have been outstanding for a long while so there probably needs to be a discussion about the maintenance status of this repo. I have been working on https://github.com/arlyon/async-stripe for probably 18 months now building on top of the work I did in this PR #151. Even with maintainer status, I didn't want to merge what was likely to be a fairly significant breaking change without input from you guys (especially with the knowledge now that you have been targeting master internally) and never got any traction on #174 or #150 so started the fork which has now diverged by about 350 commits or so. Initially the plan was to renovate the internals and upstream to allow for pluggable runtimes as well as automatic codegen but as time went on it gets harder and harder to merge.

A summary of these changes can be found here arlyon/async-stripe#79.

So that leaves us in a strange state. After working on this for 18 months I am reluctant to upstream the changes as the diff is horrendous and we'd essentially be overwriting this entire repo. Additionally there are a not insignificant number of people using the crate which is about to see the release of 0.15 so a) stripe-rs would jump 3 significant versions, and b) cargo has no nice way to 'mirror' releases or handle renames so those users would be abandoned.

My question then is, given the long list of improvements in the fork, and the limited bandwidth you guys have, whether you are comfortable with adopting async-stripe internally and contributing your time to that project instead. If you'd like to chat offline you can reach me at [email protected]

[stearnsc]

The current system for this crate isn't really functional, and I think having a clear choice for stripe in the rust ecosystem is important. To that effect, sunsetting this crate in favor of async-stripe might make the most sense. I don't know how difficult it would be to move our internal usage from stripe-rs over to async-stripe, but looking at your changelist, my instinct is it wouldn't be too bad (although we might need to re-do some of the changes we've made here since your fork).

It would be nice if there were better tools in Cargo / crates.io that would allow us to gracefully move users over from stripe-rs to async-stripe, but I think that might just be a cost we have to eat. @seanpianka any thoughts?

[arlyon]

I'll add as an additional comment I just wanted to say that I am very grateful for the work you guys at wyyerd have done to get this library off the ground, and I have been really enjoying the past 18 months getting it to the place it's at now.

[seanpianka]

The current system for this crate isn't really functional, and I think having a clear choice for stripe in the rust ecosystem is important. To that effect, sunsetting this crate in favor of async-stripe might make the most sense. I don't know how difficult it would be to move our internal usage from stripe-rs over to async-stripe, but looking at your changelist, my instinct is it wouldn't be too bad (although we might need to re-do some of the changes we've made here since your fork).

It would be nice if there were better tools in Cargo / crates.io that would allow us to gracefully move users over from stripe-rs to async-stripe, but I think that might just be a cost we have to eat. @seanpianka any thoughts?

I wholeheartedly am in favor of sunsetting stripe-rs in favor of the excellent work that @arlyon has done building on top of this existing crate. He's added lots of excellent features to improve the user experience and redirecting all of ours' limited capacity for maintenance and extension of this crate towards async-stripe is the right move in my eyes.

As far as moving existing users of stripe-rs from crates.io to async-stripe, I think the best we can do is use whatever deprecation tools are offered by crates.io and make it clear in the README of this crate that async-stripe is the successor in this regard. A migration guide would be going the extra mile, however I think @arlyon has done a good enough job with the documentation of async-stripe that users shouldn't find too much trouble here.

Thanks again for the work you @stearnsc (and others) have done maintaining this crate up until now! It has filled the void that Stripe themselves have conspicuously left empty in the Rust ecosystem. I'm looking forward to further development efforts of async-stripe!