Split server and client repos #47
Description
While never released, initially I thought these would be in the same repo since testing one effectively requires an implementation of the other, and in that, they're in some way coupled (since there are yet to be other implementations).
However, it became more clear that they should be separate Distributions. If I install a server update, there's no reason for all of the client applications to upgrade a dependency for no benefit. Moreover, the server has some hefty dependencies (currently boost and libarchive). It shouldn't be required that every client app has those installed to build the client library, nor should they need to even consider it. The server library is noise to 99% of people using this functionality, and they only care that the server implementation exists somewhere. Unlikely people will develop against it. I think I've made my point.
Once they're separate Distributions, then it becomes more obvious that they should have decoupled versions. That starts to make the git repo a bit awkward. Do we have 2 changelogs? How do we tag releases?
It's currently useful to have these tightly coupled in versioning and always keep them constrained, mostly for convenience. However, eventually there will be "older releases" on this repo for download. We should decouple the client and server repos down the road, and one option for testing will be to download an older version of the counterpart from this current state for testing, eventually mutually installing each other's implementations.