Follow Hafas' naming for the API version key

[vkrause]

As per discussion in PR #7.

[derhuerst]

Technically, this is a breaking change, but AFAIK no one uses transport-apis yet.

[vkrause]

Technically, this is a breaking change, but AFAIK no one uses transport-apis yet.

Valid point. While it is IMHO still too early to follow strict compatibility rules (we'd need some more content in here first), we probably should make it explicit when we want to start doing that. PR #7 and automatic JSON validation would seem like good prerequisites for that, at least for Hafas endpoints.

[derf]

So you're suggesting we should not just define and validate generic JSON attributes, but also endpoint-specific properties below options, and bump the version when those change?

[derhuerst]

I think doing this is helpful, if it's not too detailed.

Validation or not, if we renamed version to ver, that would break clients depending on ver. This is why I consider it a breaking change. As @vkrause said though, at this state of the project, that is not relevant yet.

[vkrause]

Right, this case shows why we would want some validation for this as well. What I tried to do here is fix the current inconsistency between data and documentation regarding options.ver vs. options.version, something that would break client code relying on either one of those variants. As said elsewhere I don't care which variant we agree on, as long as it's consistent everywhere :)