Skip to content
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

[API] Make the ?lock_kind parameters non-optional to avoid breaking the library users after they upgrade their opam root #5488

Merged
merged 1 commit into from
Feb 21, 2025

Conversation

kit-ty-kate
Copy link
Member

Fixes #5487

The current code shows issues with our internal uses of such functions, opening as a draft for now and I will point out where the issues are.

Copy link
Member Author

@kit-ty-kate kit-ty-kate left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't it be the same lock_kind as the one given as argument?

@kit-ty-kate kit-ty-kate added this to the 2.4.0~alpha1 milestone Sep 25, 2024
@kit-ty-kate kit-ty-kate force-pushed the explicit-lock-kind branch 3 times, most recently from ac4a7d6 to 0472d10 Compare February 11, 2025 01:16
@kit-ty-kate kit-ty-kate changed the title [API] Make ?lock_kind always non-optional to avoid breaking the library users after they upgrade their opam root [API] Make the ?lock_kind parameters non-optional to avoid breaking the library users after they upgrade their opam root Feb 11, 2025
@kit-ty-kate kit-ty-kate marked this pull request as ready for review February 11, 2025 01:16
@kit-ty-kate kit-ty-kate requested a review from rjbou February 11, 2025 01:16
…he library users after they upgrade their opam root
@kit-ty-kate kit-ty-kate merged commit 4cde2e8 into ocaml:master Feb 21, 2025
44 checks passed
@kit-ty-kate kit-ty-kate deleted the explicit-lock-kind branch February 21, 2025 15:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants