Having the implementation inside the repository would be nice as it would allow me to make releases for all implementation crates in one go whenever changing something from the deadpool crate (0.8 is incoming).

But then I wonder if I should rather extract the Manager trait into a separate crate which can be 100% stable and reduce the version dependencies even more. See #90

I don't know if it's a good idea to have everything inside of the deadpool repository, why don't you do something more similar to r2d2 ?

I have implemented deadpool for a ArangoDB backend, deadpool-arangodb, and wanted to ask how i should proceed with publishing? I don't want to just use the deadpool- "namespace" without asking. So...can i publish it as deadpool-arangodb or should i use a different name? I am also open to moving the code inside the deadpool repository.

Thank you for asking. Others have just used that "namespace" and created "inofficial" pool implementations based on deadpool.

Deadpool 0.9 is about to be released (0.9 Milestone). The only blocking issues are #149 and #152. I have mostly working code for both of them and I plan to make that release by the end of this week.

After that 1.0 is all about final API stabilization and making it even more production ready by adding support for tokio-tracing, etc.

At the current state of deadpool I'd prefer the code being part of the deadpool codebase so it becomes part of the CI tests. If you want to contribute that code I'd be more than happy to accept a PR. This is not a must and if you prefer to keep control over the code I can understand that.

Great. Then i'll create a PR today or tomorrow, to move my code into the deadpool codebase.