SemVer policy for pre-1.0 dependencies #442
Labels
do-for-4.0
This should be resolved before we do a 4.0 release
Comments
Closed
|
Drafted #443 |
Merged
|
If the And here is the PR for the |
pinkforest
added a commit
to pinkforest/curve25519-dalek
that referenced
this issue
Nov 30, 2022
As discussed in dalek-cryptography#442 this change set the digest feature as optional.
Merged
pinkforest
added a commit
to pinkforest/curve25519-dalek
that referenced
this issue
Nov 30, 2022
As proposed in dalek-cryptography#442 this makes rand_core an optional feature that is not covered by the SemVer public API stability guarantees.
pinkforest
added a commit
to pinkforest/curve25519-dalek
that referenced
this issue
Nov 30, 2022
As proposed in dalek-cryptography#442 this makes `digest` an optional feature that is not covered by the SemVer public API stability guarantees.
pinkforest
added a commit
to pinkforest/curve25519-dalek
that referenced
this issue
Nov 30, 2022
As proposed in dalek-cryptography#442 this makes `rand_core` an optional feature that is not covered by the SemVer public API stability guarantees.
rozbb
added a commit
that referenced
this issue
Dec 8, 2022
As proposed in #442 this makes `rand_core` an optional feature that is not covered by the SemVer public API stability guarantees. Co-authored-by: Michael Rosenberg <[email protected]>
rozbb
added a commit
that referenced
this issue
Dec 8, 2022
As proposed in #442 this makes `digest` an optional feature that is not covered by the SemVer public API stability guarantees. Co-authored-by: Michael Rosenberg <[email protected]>
|
This was resolved in: Can be closed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Something I think should be documented prior to the 4.0 release is the SemVer policy for pre-1.0 dependencies which are part of the public API, namely
digestandrand_core.I would suggest exempting these APIs from SemVer guarantees around major versions, allowing them to be updated with a minor version bump only.
It might be worth considering making both of those dependencies optional and noting if they're activated, you're opting into something which isn't stable around major versions. That would mean the feature profile one receives with the default features activated is stable around major versions.
The text was updated successfully, but these errors were encountered: