NickCraver
commented
3 years ago Heads up: the repo split has begun - I'll work on moving issues, etc. over to https://github.com/DapperLib/Dapper.Contrib and cleaning up the folders in the main repository here next.
Hey all, As Marc and I plan on the future of Dapper on the technical side (we’re looking at current APIs, which platforms to support, using generators to help with AOT scenarios, etc.), one thing is apparent: Dapper.Contrib isn’t a goal we are after (pointing most users to Entity Framework or alternatives there). But, we also realize a number in the community use it.
What we’ve done lately is move Dapper to this new org: https://github.com/DapperLib, this is in preparation to more cleanly lay things out. It’s our intent to split Dapper.Contrib out of the main repository, into a DapperLib/Dapper.Contrib repository of its own, potentially with another crew helping maintain it long-term.
We’re just being up front here: we don’t use it, and aren’t invested in it as a result. That’s just the reality of anything when your time is maxed out and something is out of sight. The pains and gaps just are not visible to us, relying 100% on community input of what’s needed and what’s problematic. It may seem backwards, but that takes even more time (both trying to understand the initial problem, and then if the big picture and specific solution makes sense, both now and directionally). To be blunt: we can give API advice, but aren’t in a position to intelligently judge what Dapper.Contrib should do.
Most of the contributions there in the past several years are almost entirely breaking changes - currently versioning in step with Dapper’s core...that also presents problems.
In short: there are many reasons to split it out and few reasons to keep it in the main repository. I think we’ll likely pause Dapper.Contrib bits until we have Dapper vNext ready (in which we plan to move Column and Table attribute functionality into core), because the shape of Dapper.Contrib’s bottom layer would change greatly.
I’m posting this here ahead of time so this isn’t a surprise and it’s something we can reference. Yes, this does mean a lot of older PRs will need to close, but unfortunately they were breaking to begin with. I hate closing PRs, especially from new contributors, but letting a change that can’t be taken sit indefinitely isn’t fair either, so we need to go through and clean up. Luckily though, a more comprehensive solution to most of the Contrib-related PRs is coming through vNext of the core library.
The next steps in mind are:
If anyone has feedback or ideas, please comment here. We’ve never done this before...and we’re as new to it as anyone. Ideas welcome!