It looks like recently some changes had been made to move away from async_std in this library, but it still didn't work for me using Tokio because the Cargo.toml only had options for SQLx to be run with async_std. Unfortunately, allowing Tokio means moving to SQLx's features system, which will break backwards compatibility, but it will be worth it to complete the move away from async_std.
The only functional change made here is exposing SQLx's runtime and TLS features combinations to allow for any configuration. In terms of versioning, I just changed it from 0.4.0 to 0.4.1 but since this is not backwards compatible it might be more suitable to change it to 0.5.0. Technically it shouldn't matter much according to semantic versioning because since this is pre-1.0.0 the API isn't considered public and hence anything can be subject to change.
Either way, this change is very minimal, so just a quick yes or no and an explanation should be all. Thanks.
It looks like recently some changes had been made to move away from async_std in this library, but it still didn't work for me using Tokio because the Cargo.toml only had options for SQLx to be run with async_std. Unfortunately, allowing Tokio means moving to SQLx's features system, which will break backwards compatibility, but it will be worth it to complete the move away from async_std.
The only functional change made here is exposing SQLx's runtime and TLS features combinations to allow for any configuration. In terms of versioning, I just changed it from 0.4.0 to 0.4.1 but since this is not backwards compatible it might be more suitable to change it to 0.5.0. Technically it shouldn't matter much according to semantic versioning because since this is pre-1.0.0 the API isn't considered public and hence anything can be subject to change.
Either way, this change is very minimal, so just a quick yes or no and an explanation should be all. Thanks.