8000 hashes: Release `v0.13.0` by tcharding · Pull Request #1917 · rust-bitcoin/rust-bitcoin · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

hashes: Release v0.13.0 #1917

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

Merged
merged 1 commit into from
Aug 24, 2023

Conversation

tcharding
Copy link
Member
@tcharding tcharding commented Jun 20, 2023

In preparation for hashes release, bump the version. Depend on new version in rust-bitcoin.

Note the bitcoin-private addition to the lock files is because we temporarily have two bitcoin_hashes dependencies and the secp one (v.0.12.0) depends on bitcoin-private.

@tcharding tcharding force-pushed the 06-20-hashes-release branch from 63b37c7 to dd9448d Compare June 27, 2023 23:15
@tcharding tcharding changed the title WIP: hashes: Bump version to 0.13.0 hashes: Bump version to 0.13.0 Jun 27, 2023
@tcharding tcharding force-pushed the 06-20-hashes-release branch 5 times, most recently from 9119833 to 471c48c Compare June 29, 2023 03:59
@tcharding tcharding force-pushed the 06-20-hashes-release branch 3 times, most recently from b8d4990 to 3fe2aff Compare July 14, 2023 05:14
@tcharding tcharding force-pushed the 06-20-hashes-release branch 3 times, most recently from a8c3c8c to 6901946 Compare August 9, 2023 01:20
@tcharding tcharding changed the title hashes: Bump version to 0.13.0 Depend on hashes v0.13.0 and secp256k1 v0.28.0 Aug 9, 2023
@tcharding tcharding changed the title Depend on hashes v0.13.0 and secp256k1 v0.28.0 Depend on hashes v0.13.0 and secp256k1 v0.28.0 Aug 9, 2023
@tcharding tcharding force-pushed the 06-20-hashes-release branch from 6901946 to ae652b7 Compare August 9, 2023 01:32
@tcharding tcharding force-pushed the 06-20-hashes-release branch from ae652b7 to 91f00cd Compare August 17, 2023 01:08
@tcharding tcharding changed the title Depend on hashes v0.13.0 and secp256k1 v0.28.0 hashes: Release v0.13.0 Aug 17, 2023
@tcharding tcharding force-pushed the 06-20-hashes-release branch 3 times, most recently from f70734f to 6aa6c9e Compare August 17, 2023 01:49
Add a changelog entry and bump the version to 0.13.0

Does not include changes to `bitcoin` to depend on the new version.
@tcharding tcharding force-pushed the 06-20-hashes-release branch from 6aa6c9e to 53f6838 Compare August 24, 2023 02:29
@tcharding tcharding marked this pull request as ready for review August 24, 2023 02:31
@tcharding
Copy link
Member Author

@apoelstra since we no longer have to do the hashes/secp release dance hashes is ready for to release I believe.

@sanket1729 can you review this one please, we are a bit thin on reviewers right now.

Copy link
Member
@sanket1729 sanket1729 left a comment

Choose a reason for hiding this comment

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

utACK 53f6838 . I am not sure about the exact nature of release dance between various crates in rust-bitcoin. This code and changelog entries looks good.

@tcharding
Copy link
Member Author

Thanks bro!

@apoelstra
Copy link
Member

Nice! We should be able to release this, since it's (nearly) a leaf crate.

Copy link
Member
@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

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

ACK 53f6838

@apoelstra apoelstra merged commit cdbd4be into rust-bitcoin:master Aug 24, 2023
@apoelstra
Copy link
Member

Tagged and published.

@tcharding tcharding deleted the 06-20-hashes-release branch August 24, 2023 23:28
@stevenroose
Copy link
Collaborator

The

Convert enum `crate::Error` to struct `crate::FromSliceError`.

element is in the changelog twice.

Also, isn't it really unfortunate we have to do a breaking semver bump just for this one method? The hex module could just be deprecated and "archived" to avoid a breaking change.

@tcharding
Copy link
Member Author

Fixed changelog in #2048

Also, isn't it really unfortunate we have to do a breaking semver bump just for this one method? The hex module could just be deprecated and "archived" to avoid a breaking change.

I don't understand this bit?

@apoelstra
Copy link
Member

@stevenroose interesting idea that we could've done a deprecation cycle for hex. I'm not sure why that didn't occur to us. It's not obvious how to do this since we want the hashes::hex symbol to refer to the hex-conservative crate now, so we need to move the module out of the way somehow.

I'm happy to double-back and do a 0.12.1 release if we think there's a way we could make the transition easier.

@tcharding
Copy link
Member Author

OTTOMH we can't deprectate because we re-export at the same path. Also, the code is literally exactly the same just coming from a different crate (all the code was cut and paste). (I don't remember 100% that we did not add stuff after the cutnpasta)

@apoelstra
Copy link
Member

If the code is literally exactly the same, we arguably don't need a breaking release.

But I think it did change, though I don't remember how.

@tcharding
Copy link
Member Author

No technical argument right now but I get a bad feeling about changing a dependency to a different crate silently. Even if we personally know we just cut and pasted the code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0