Documentation is available through either a ReDoc or SwaggerUI interface. Three versions of the documentation are published:
The API that is currently deployed to production Citrination environments. All client libraries that are publicly available have been generated from this API definition.
The current release candidate of the API. All production Citrination environments should support this version of the API, though that support is not guaranteed.
The development branch of the API. There is no expectation that this version of the API is supported on any production environments.
- Update the
develop
branch with potential changes to the API- Create a new branch off of
develop
- Make changes to your new branch
- Open a pull request from your branch against
develop
- Create a new branch off of
- Update the
release
branch with a new release candidate- Verify that the development interfaces are correct
- Wait until production Citrination instances support the changes to make
- Open a pull request from
develop
againstrelease
- Update the
master
branch with a new API version- Verify that the release interfaces are correct
- Update the API version on the
release
branch according to conventions - Open a pull request from
release
againstmaster
- Update
develop
with any changes- In case any changes were made to the
release
branch, merge it back intodevelop
- In case any changes were made to the
- Avoid breaking changes unless absolutely necessary
- Use semantic versioning for the API version number with the following meanings:
- Revision: Changes to documentation or changes that otherwise do not affect behavior
- Minor: Added functionality or schema elements
- Major: Breaking changes
- Assume that client libraries will be auto-generated based on this documentation
- Create directory structures that mirror package hierarchies
- Make sure to support strongly-typed languages by defining both type and format for variables