When a non-backwards compatible change is made to the api, the version will be incremented to "1.1". (Hopefully by that time the spring bug restricting the use of a "." in the uri is fixed)If/when (hopefully never) we make a major change to the entire rest setup, we will change this to v2. (e.g. change from json to kson)
Each resource can also refer to different underlying api object versions. Each object declares a resourceVersion property that specifies which version of the API it is required to work in. This works similar to an @since annotation.
The actual visible version of the '''module''' will be incremented independenty from openmrs AND from the version of the rest api.TODO: When necessary, insert table of rest module version to rest api version to openmrs required version.
There were discussions about using the Media-Type header instead of a number in the uri. However, looking at a lot of major players in the api space, we decided to go with a global api version in the uri.