update deprecation versions and bump minor version #809
Conversation
|
As an aside, I'd like to point out how easy Basically,
You can see that even wih jj there are a lot of steps here, but git additionally insists that you push branches individually and checkout a bunch of arbitrary things while you're working. Then if I need to update these, I can similarly do an update commit, duplicate and squash it into each of the branches (will check on IRC if I can do these in one shot..), then `jj git push --remote github -b 'glob:2025-06_tbd*'`` again to push everything. |
|
Man :/ if we had done the deprecation properly we would've noticed all the uses of these deprecated functions in our unit tests and serde impls ... and then noticed that the replacements are wildly inconsistent (some take Sigh. |
|
Also the serde impls for Schnorr signatures and ECDH secrets use |
|
Ok, actually we did correct a bunch of these in 0.31. |
|
Will conflict with #806. Probably easiest to get this one in first. |
|
Heh, thanks for the ACK -- but this does not bump the minor version like it claims. |
We accidentally released 0.30.0 and 0.31.0 with "future" deprecations. Most users will not see these since the lint for them is different from the normal deprecation warning (and it's undocumented except to say that we "should not use" future deprecations, even though it works and there is no alternative). Somewhat fortunately, in 0.30.x we messed up the deprecations and provided an inconsistent and weird API to replace the old functions. But because we messed up the deprecation messages, we can pretend we didn't do it and just mark the deprecations as having started in 0.31.x
We have duplicated funny logic in the PartialOrd and Ord impls of SerializedSignature. No need to duplicate: just have PartialOrd call into Ord.
Ouch! |
We accidentally released 0.30.0 and 0.31.0 with "in future" deprecations. Most users will not see these since the lint for them is different from the normal deprecation warning (and it's undocumented except to say that we "should not use" future deprecations, even though it works and there is no alternative).