Created by: richardwhiuk
Don't change the API version which is exposed in crate::API_VERSION
.
This is useful, because often the API version needs to be passed on the API (e.g. as a query parameter), at which point it's useful if you can use the API version which the library itself is exposing.
As such, we change the logic such that:
-
If the API version isn't set, we don't expose it.
-
If it is set, we leave it well alone.
-
Always pass a package version:
- Pass in the passed package version by preference
- Pass in the API version if it's not.
- If the API version isn't set, we use 1.0.0
- If it is set, and isn't a valid semver, we append .0 such that we have something with three digits (so that an API version of 1 works).
This is obviously breaking, as we are changing the exposed API version for a bunch of crates, but it's the right long term fix.
Rust Server Technical Committee
- @frol
- @farcaller
- @bjgill
PR checklist
-
Read the contribution guidelines. -
If contributing template-only or documentation-only changes which will change sample output, build the project before. -
Run the shell script(s) under ./bin/
(or Windows batch scripts under.\bin\windows
) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run./bin/{LANG}-petstore.sh
,./bin/openapi3/{LANG}-petstore.sh
if updating the code or mustache templates for a language ({LANG}
) (e.g. php, ruby, python, etc). -
File the PR against the correct branch: master
,4.3.x
,5.0.x
. Default:master
. -
Copy the technical committee to review the pull request if your PR is targeting a particular programming language.