New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate withMonitor or fuse withMonitorRef #281
Comments
+1 |
I agree to make such patch, but I'm not sure what will our strategy be here, and as consequence what to put into deprecation message. Will |
I've deleted my comments/questions about the branching process. We can discuss it on the mailing list instead. @qnikst that deprecation message looks fine to me. |
@hyperthunk how much effort do you plan to put into d-p now, if there will be enough changes for the major release, we can just remove the message, and write the change to the changelog. If you want to have a minor cleanup release, then deprecation message is fine. |
I'm going to pull together a fix for the tracing bugs and a hope to close out a number of other open issues, so let's sit tight until I've got enough changes for a major release. |
Ok, then we should verify that everything is in master and provide deprecation message, will you do that yourself or want me to take care of that. |
I'll do it once the rest of my patches have been merged. |
I think it's confusing to have both
withMonitor
andwithMonitorRef
. The two functions are nearly identical. Could we either deprecatewithMonitor
, sincewithMonitorRef
is all that's needed, or (at the cost of a breaking change) make the naming consistent with base: i.e.(as in
mask_
andbracket_
inControl.Exception
and elsewhere)If we deprecate
withMonitor
now, it leaves us free to recycle that name to make the naming consistent in a later release.The text was updated successfully, but these errors were encountered: