Abandoned??

[ptdecker]

It's sad to see that this crate seems to be abandoned by a maintainer. It is currently key for us given that it provides connection pool support for the Oracle client. Are there any efforts to establish a new maintainer?

[sfackler]

I would categorize it as being in more of a maintenance mode than anything. Are there specific issues you are running into?

[ptdecker]

Hey, thank you for responding!! I really appreciate you taking the time.

No, we have no specific issues right now. The issue came up as we're moving forward with exposing some more of the connection timing and pool settings in our configuration as we move our systems into full production.

In doing so, I observed the number of open PRs, unresolved issues, and 0.y.z version indicating of course that the interfaces are still in flux. And, these thus led to the concern because our system will go live for a major global financial institution soon under a high system load. As we head into that, we're doing all we can to make sure our bases are all covered. I'm just your typical dev worried about sitting on 1am dev one calls on a system whose connection pool foundation may not have someone there to help (of course, fully understanding too that it is open source, community maintained, and without warranty as expected). But, I would be less nervous if there was regular activity as transient dependencies change, Rust versions change, issues are filed, etc.

Again, thank you for taking the time, for the efforts you've put into this crate, and for your support of the Rust community.

[sfackler]

and 0.y.z version indicating of course that the interfaces are still in flux

I would look at how the API is actually evolving than making assumptions about how versions are tracked. The interfaces here haven't had a breaking change in 8 years.

This is a pretty simple library, and there just isn't really much of a need for a ton of churn. It works well enough, and there hasn't been a need to cut a new release in a few years. If something comes up I'm happy to do so.

[ptdecker]

For my immediate efforts, these four open issues are probably relevant:

• Document relationship between min_idle, idle_timeout and max_lifetime #127
• Fail Fast for Certain Errors #147
• get_timeout exceeds timeout #116
• r2d2 threads remain alive for up to 30s after pool shutdown #99

I'll be sure to study these closely.

Thank you for responding. If the interfaces have been stable for 8 years, why not take it to 1.y.z status? I think there was a question about the roadmap for this five years ago