Enforce consistency of version number in config vs. raml

[schuderer]

When developing a model/API and incrementing its major version in the config file, it's easy to forget updating the RAML file's version property. The result is that everything seems to work, until you want to reach the API using the URL expected from how the config's version was set.

So, if the config specifies model: version: '1.0.0' and the RAML file still states version: v0, there is no error or warning given. The model is handled/saved using version 1(.0.0), whereas the API is initialized using v0. This of course will lead to problems down the road.

Solution alternatives:

1. When creating the API, also check whether the major version number matches and raise an error if it does not. Most explicit solution, but requires changes in two files.
2. Use the config's major version number when creating the API, but log a warning if there's a mismatch (this flouts RAML's contract character, however)
3. Automatically correct the RAML file with a warning (make its version number consistent with the config). This also automatically changes the user's RAML contract in the background, may lead to version/release confusion...
4. Put the version in the RAML only (how to deal with minor versions etc?)

I personally favor option 1 because it's clear and straightforward, making the user aware that the RAML is in fact a contract to explicitly pay attention to.

[schuderer]

Actually, this check is already included. User error ;)