bitcoin: Set version number

[tcharding]

During the recent release cycle we left bitcoin on the last rc version.

Set the version number to v0.33.0-unreleased to make it obvious what it is.

Close: #2724

[coveralls]

Pull Request Test Coverage Report for Build 8930774910

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 83.163%

---

Totals
Change from base Build 8924682530:	0.0%
Covered Lines:	19194
Relevant Lines:	23080

---

💛 - Coveralls

[apoelstra]

Can we set it to 0.32.99, or 0.33.0-rc.0 or something, so it's clear that we're incompatible (or soon will be) with the recent 0.32 release?

[tcharding]

Is that something we want to do across the all our crates? It implies an additional PR right after release of every crate. Now I think about it it does give us a nice checkpoint for doing other "this should be done as the first thing after release" things which have come up before, we can do the "set version to x.y.z-pre-release" and make the PR depend on other PRs same as we do for release tracking PRs?

[apoelstra]

Is that something we want to do across the all our crates?

Any crates for which we have an rc cycle, yes. But I think that might be only this crate (though we should do it in rust-miniscript and maybe rust-secp). Many of our "edge crates" like io, jsonrpc, hex-conservative, etc., we usually just do one-shot releases whenever we need them, and we don't usually have separate release branches. And I think this is fine for those crates.

[tcharding]

No worries, I haven't fully understood the why, as in why would rust-bitcoin master branch have bitcoin on version 0.33.0-pre but hashes have the current released version?

[tcharding]

I used v.033.0-unreleased

[apoelstra]

No worries, I haven't fully understood the why, as in why would rust-bitcoin master branch have bitcoin on version 0.33.0-pre but hashes have the current released version?

Because bitcoin has an rc branch and hashes does not. (Arguably hashes should have an rc branch and follow the same process but that's a lot of extra process for a crate that really doesn't change much, plus it would add complexity managing release branches for muliple crates off of one repo.)

I used v.033.0-unreleased

Will this cause cargo grief if/when we release 0.33.0? We don't really care about weird cargo interactions because we'll never publish the -unreleased one. At the very least, it is easy to change -unreleased later without having old stuff permanently sitting on crates.io.

[apoelstra]

In 91eed01:

It appears you have changed the commit message but have not changed the diff :)

[tcharding]

It appears you have changed the commit message but have not changed the diff :)

Gawwwd damn

[tcharding]

Changes were not comited from yesterday :(

[tcharding]

In case you have a suggestion for me, the reason this happens occasionally is (that I'm rushing doing 10 things) because I use the up arrow in the shell to get at ci --amend --no-edit -n -a but if I have recently been doing something more involved I might have added files manually and used ci --amend --no-edit -n (without the -a). Then when using shell history I don't notice the -a is missing. Do you have a better process?

I should obviously just slow down and take a breath before pushing ...

[sanket1729]

Do we care about users that are testing using master and expect the types to be compatible with other crates that use bitcoin 0.32?

[tcharding]

Oh good observation @sanket1729! This might actually be a feature not a bug, at least when I've been testing rc releases I've specifically changed the version number of all the crates in the stack to force fails if I've missed updating the manifest of some crate and the compiler is still pulling from crates.io - but I'm not 100% sure this is the most time efficient way to do it.

If devs are testing master they can also just change the version number locally, right?

[apoelstra]

Do you have a better process?

You can use Ctrl+R then -a. And use a autocompleter like atuin which will show you a list of all the possible choices in your Ctrl+R list.

Do we care about users that are testing using master and expect the types to be compatible with other crates that use bitcoin 0.32?

We "care" in the sense that we want them to quickly see compiler errors in case they forget to patch something :). But I think this will happen regardless of version number, because cargo won't consider a crates.io crate to be the same as a local crate.

In general master will not be compatible with any released version.

[apoelstra]

ACK 46e0ce5

[tcharding]

In general master will not be compatible with any released version.

Yeah, that's what I meant about feature-not-bug, we break the API so often ...

[tcharding]

You can use Ctrl+R then -a. And use a autocompleter like atuin which will show you a list of all the possible choices in your Ctrl+R list.

Legend, thanks!

[apoelstra]

If you do install atuin, note that it'll default to triggering on both Ctrl+R and up-arrow. The up-arrow behavior is insane and you should just disable it.

The docs also talk a big game about being able to upload your shell history to some server, and also they have a server you can use, but don't worry everything is encrypted wink wink. This is also insane and makes me distrust the project, but you can totally ignore this and just install it locally.

[sanket1729]

ACK 46e0ce5

[tcharding]

Cheers, I did install it and I did not enable the server feature. I didn't dive any further into it yet though.

[tcharding]

Merge please, has two acks.