[Documentation] compatibility matrix for HDK,HDI and HC

[nphias]

[Documentation] compatibility matrix for HDK,HDI and HC

[ThetaSinner]

I think this is a good idea. It's not obvious what is compatible with what from anywhere I can see.

@steveej do you think this is something the release automation could do as part of putting out a release? We know either the current version (if not publishing) or the version to be published (when there are changes and we are publishing) for each crate. So it should be possible to write that information to a markdown table or similar?

[steveej]

compatibility is not straight forward and we can't exhaustively test the entire space of potential applications written. at this moment i don't have the breadth for an exhaustive answer, however i want to point you to a PR that addresses an aspect of compatibility on a per-callback level: #2366

we can still make some simplified compatibility assumptions:

a safe way i see of reducing this to a single level is pessimistically assuming that any hdi/hdk/holochain change leads to full incompatibility.

a middle-way is to assume compatibility within the minor version series, which is also the intention of our release management.
for example, versions within the holochain-0.1 and holochain-0.2 branches respectively should be compatible with each other. for that we could probably construct a matrix that we extend over time. ideally this it would be guarded by best-effort compatibility tests. e.g. it would keep test DNA artifacts around from the time of branch creation, which can subsequently be used to test for binary compatibility.

[nphias]

Thanks @steveej .. forgive my lack of knowledge on internals, I am not sure how the genesis self check per callback relates to version compatability.

I guess I am interested as a happ dev, in how many different versions of holochain I can run under a conductor to support legacy happs etc. and if i would need to run mutiple conductor versions?
Does compatibility mean i could bridge cells between different holochain versions (migration strategy) ?

I realize holochain comprises of like 30 different crates all of which have to follow version control.. would it be easier to grok this if there was a leading crate that others followed?.. Could we say for example that this version of the conductor supports holochain 0.1 and 0.2. how does that relate to HDK versions (the language/API that conductors operate by)?

I think it would be very helpful for devs to have access to a wiki with a version matrix.. which includes reference to the versions that are LTS, and planned to be LTS.. like ubuntu does on their wikipedia page. Where would such a matrix live, on the holochain readme git repo?