Remove core2 depedency

[tcharding]

The core2 crate was unilaterally yanked borking our build.

Remove the dep. This will require a semver violation to release a set of breaking changes in a point release for the 0.2.x series.

... And add a bunch of lint patches.

[tcharding]

oh this is a backport of #105 - I didn't see that till just now.

[apoelstra]

ACK 1830417; successfully ran local tests

[apoelstra]

Actually, can you add a commit which fixes the CI script? It's trying to pin a dependency that no longer exists.

[apoelstra]

ping

[Kixunil]

Yanked version is not a reason to release a semver breaking change in a patch version since yanking is backwards-compatible on purpose. It needs to bump to 0.3 instead. We could semver-trick everything except HexToBytesIter, I think (and even HexToBytesIter can be a thin wrapper over 3.0 one with conversions).

[apoelstra]

yanking is backwards-compatible on purpose

What? We literally cannot build this package except by having old lockfiles laying around which cargo will not generate for us. How is that backward compatible?

Anybody who has old lockfiles available to use can use those lockfiles to avoid this patch release.

[apoelstra]

ce3629b needs rebase

[tcharding]

Force push is rebase and add pinning patch.

[apoelstra]

I think we should give @Kixunil 2 weeks to provide a working lockfile we can commit to this repo instead of removing the core2 dependency.

Kix, to save you some time,

• cargo build in a fresh clone fails because cargo cannot find core2
• cargo update -p core2 fails with "package ID specification core2 did not match any packages"
• cargo update -p core2 --precise 0.3.2 and cargo generate-lockfile and cargo add core2 also fail

Otherwise we should just break whatever imaginary users out there who are able to produce lockfiles and are unable to avoid updating them.

[Kixunil]

We literally cannot build this package except by having old lockfiles laying around which cargo will not generate for us. How is that backward compatible?

FTR, I believe cargo should have some kind of --force flag that ignores yanking and instead of yanking being a boolean flag it should come with a reason for yanking. But that's besides the point. This change is objectively SemVer breaking and releasing it in a SemVer-compatible patch is a needless violation of SemVer.

I don't see a significant problem with just releasing a SemVer-breaking release and dropping support for the old one because it's unmaintainable. We were always recommending that people have 1.0 in APIs, so updating their Cargo.toml will not break those who listened to the recommendation and I don't think we're obligated to go out of our way to support those who didn't since by doing so they knowingly and willingly accepted the potential breakage.

That being said, if you really want to fix CI without issuing a SemVer-breaking release for some reason, I will try to get the lock file in. I don't think it will be super-complicated. (Besides, we should really just use lock files anyway.)

[apoelstra]

I don't see a significant problem with just releasing a SemVer-breaking release

...this then needlessly makes multiple bitcoin_hashes 0.14.0 types incompatible with 1.0, which means that current rust-miniscript versions can't be used with software using the 1.0 stack.

We were always recommending that people have 1.0 in APIs, so updating their Cargo.toml will not break those who listened to the recommendation

How do we "put 1.0 in APIs" for rust-bitcoin 0.32.x?

That being said, if you really want to fix CI without issuing a SemVer-breaking release for some reason, I will try to get the lock file in.

Okay, thank you.

[Kixunil]

Oh, WTF, I thought 0.2 was already using the semver trick. OK then, I will check the Cargo.lock thing.

[apoelstra]

Closing this. We have a lockfile we can use now.