[FEATURE] Server and client versioning

[hasan7n]

Is your feature request related to a problem? Please describe. Given that some breaking changes have happened (and will keep happening) with the server and the client, a lot of boilerplate code will start showing up just to cover edge cases with backwards compatibility.

Describe the solution you'd like

We will follow {Major}.{Minor}.{Patch} versioning for both the client and the server:

Compatibility rules

• Clients cannot talk to newer servers, e.g. Client 1.1 cannot talk to Server 1.2
• Clients CAN talk to older MINOR version servers, e.g. Client 1.2 can talk to Server 1.1.
• Clients cannot talk to DIFFERENT MAJOR version servers, e.g. Client 2.0 cannot talk to Server 1.13.
• Patch releases are not considered when checking compatibility.

  	Server
  Client		1.0	1.1	2.0
  	1.0	Y	N	N
  	1.1	Y	Y	N
  	2.0	N	N	Y

How/when versions will be released

• Major of the server is incremented when there is a breaking change. The client Major version is also incremented to adapt to these changes.
• Minor of the server is incremented when there are backward-compatible changes. Client Minor version is also then incremented to adapt to these changes WHILE preserving compatibility with previous minor releases of the server
• Patch releases for the client are for bug fixes and "soft" changes. Patch releases for the server are also for bug fixes or changes that are not reflected on the client.
• Only the latest patch release is supported. Users are expected to always upgrade to the newest patch release.
• TODO?: follow determined release dates (e.g. every quarter?)

How client-server compatibility check happens:

• Current approach: When communicating with the server, the client should send its version in the header of every request. A Django middleware intercepts the request and compares the version in the header with the version of the server (which is stored in django settings file). The comparison should be according to the above table. TODO: what should be the error status code of the response in case of incompatibility?
• Alternative: Check if it is feasible to have every response from the server contain the server version, even if the request failed. The client would then check the received version with its version and exit if there is an incompatibility. Possible Cons: it is not a "common" design.
• Alternative: Expose a server endpoint: api.medperf.org/version. The client would then call this endpoint before every request, and check for incompatibility. Possible Cons: This results in an extra server call each time a medperf command is invoked.

[aristizabal95]

Follow this description: https://semver.org/

It's highly discouraged to do Incompatible API changes for minor versions. If there's an exceptional case, both the client and the server should have an isolated place where backwards-compatible logic is located. Both Client and Server implement the required logic to handle communications with parties of a lower minor version.

[aristizabal95]

The api has the major version written explicitly (e.g. api.medperf.org/v1/datasets). Clients with a version mismatch will hit a different endpoint, and therefore will not communicate with the server. To provide indication as to why an error happened when trying to talk to the api, we can also provide a version endpoint that specifies what version the server is using (e.g. api.medperf.org/version). That way the client can then indicate the user what major version is required to talk to the given server.

[hasan7n]

TODO: change version to 0.1.0 inside the server and pypi setup file

[hasan7n]

handled by #354