Addressing version incompatibilities for patch versions

[pospi]

Just a note to state that I'm hitting blocks in rich cross-project collaboration due to the way Holochain is managing versioning between Rust crates. There are two related issues here:

1. SemVer is not being used to track the alpha versions
2. Dependencies of Holochain are specified too explicitly

(2) could be addressed in the process of solving (1) depending on the path taken.

I have tried mitigating (1) with tilde versioning but this still does not give me means of having flexible dependencies- eg. 0.0.42-alpha5 and 0.0.47-alpha1 are considered incompatible. ~0.0 feels way too loose, and without alignment on SemVer it's unclear what this would even mean RE alpha/beta release naming.

The end result is that every hApp codebase quickly falls into incompatibility with others, and forks / fragmentation arises to compensate. It's a very heavy maintenance & coordination burden for cross-project devs currently.

(2) is potentially an issue, though I do note that the incompatibility I'm currently hitting with bitflags is probably unavoidable (1.0.4 → 1.2.0); however, in the case of such an unavoidable dependency update then I would expect a corresponding minor version bump in Holochain core. Would also recommend limiting such updates to security patches once we get into beta territory (I'm hoping soon!) so as to avoid unnecessary backward-incompatibility with older Holochain apps.

[pospi]

We also don't have to throw the baby out with the bathwater to solve this problem. Seems to work pretty well for the Futures crate, though note that they have a . separating every numeric identifier whereas hdk etc do not:

Compiling futures-channel-preview v0.3.0-alpha.17

In this case we should be able to say =0.3 or =0.3.0-alpha and conform to patch versions for breaking changes & minor versions (with -alpha suffix) for incremental updates.

[zippy]

Yes. The pinning issue is a difficult one and a pain. We will land a repo refactor that at the very least allows each of the separate crates in our mono-repo to be versioned independently of the holochain binary, most crucially the hdk.