Zebra: Make the zebrad crate version and user agent match

[teor2345]

Currently, the zebrad crate version is 0.1.0, and the user agent is 2.0.0-alpha. We should make these versions match, so bug reports are easier to understand. (The crate version is used in zebrad version, and the output of some other commands.)

I'd submit a PR, but I'm not sure what outcome we want here. In particular, I'm not sure if we want to commit to a 2.0 semver until we've stabilised.

[hdevalence]

We had a brief discussion on discord and it seemed like we had consensus on the following versioning policy (please correct me if I'm getting this wrong):

• zebrad: match major version to NU version, so we will start by releasing zebrad 3.0.0;
• zebra-* libraries: start by matching zebrad's version, then increment major versions of each library as we need to make breaking changes (potentially faster than the zebrad version, always respecting semver but making no guarantees about the longevity of major releases).

If we do this then I think we want to set the version of all of the Zebra crates to 3.0.0-alpha.0 -- the -alpha.0 marks it as a prerelease not subject to perfect adherence to compatibility guarantees.

[yaahc]

I'm worried about using -alpha.0 releases because I've seen plenty of edge cases where they break things, I don't know the specific edge cases or ways this can cause issues so this is a bit of FUD but we should definitely be careful here.

[hdevalence]

@yaahc is your concern about us using semver prerelease tags like -alpha.0 in our crate versions or about using them to specify external dependencies? I agree that they can cause a lot of breakage, and I would not like to use them for dependencies, for the same reason I don't like git versions.

However, I think that if we're only using them for our crates within a single workspace, we will probably be okay. One major pain point is that Cargo treats prerelease versions as exact = constraints rather than the usual ^ compatibility constraints, so if different prerelease versions are used in the same dep tree everything breaks. But in our case, all of the prerelease crates are in the same workspace, so we're sure to get a unified version anyways.

[yaahc]

@hdevalence my concern was a lot more nebulous than that, I couldn't recall exactly how pre release tags can break things i only recalled seeing instances of them breaking things. You seem to be much more familiar and aware of the issues, which is essentially all I wanted. So I'm satisfied by this explanation and plan.

[hdevalence]

It sounds like there might be rough consensus on this, so I'm going to prepare a PR that changes all the versions so we have a concrete suggestion to discuss.