Unfortunately - these are all breaking changes. It's something we'll address in the next major version of Dapper, but aren't aiming to do in the current APIs due to the breaking nature (adding optional params would break all libraries compiled on top of Dapper - it's not binary compatible).

I'll leave this open for any questions, but aim to cleanup and close out in a few days if all is understood here.

Unfortunately - these are all breaking changes. It's something we'll address in the next major version of Dapper, but aren't aiming to do in the current APIs due to the breaking nature (adding optional params would break all libraries compiled on top of Dapper - it's not binary compatible).

Would adding new overloads with non optional cancellationToken papramater still be considered a breaking change?

Would adding new overloads with non optional cancellationToken papramater still be considered a breaking change?

It would not, but it would create a lot of extra methods to maintain. Given the plan to change the overall interface of how we layer in vNext, I think we'd want to add them once...and take this breaking change since people would need to compile against it anyway.

Would it instead be possible to grant directly access to the currently private methods executing this, that accepts CommandDefinitions (which does have CancellationTokens), in the mean time?