kotovalexarian-likes-github/moby--moby
1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00
Code Releases Activity
moby--moby/api/types/versions
History
Antonio Murdaca 667315576f
api: add Info struct for v1.24 
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
2016-11-07 10:01:14 +01:00
..
v1p19 Move engine-api client package 2016-09-07 11:05:58 -07:00
v1p20 Move engine-api client package 2016-09-07 11:05:58 -07:00
v1p24 api: add Info struct for v1.24 2016-11-07 10:01:14 +01:00
compare.go Add engine-api types to docker 2016-09-07 11:05:58 -07:00
compare_test.go Add engine-api types to docker 2016-09-07 11:05:58 -07:00
README.md Add engine-api types to docker 2016-09-07 11:05:58 -07:00

README.md

Legacy API type versions

This package includes types for legacy API versions. The stable version of the API types live in api/types/*.go.

Consider moving a type here when you need to keep backwards compatibility in the API. This legacy types are organized by the latest API version they appear in. For instance, types in the v1p19 package are valid for API versions below or equal 1.19. Types in the v1p20 package are valid for the API version 1.20, since the versions below that will use the legacy types in v1p19.

Package name conventions

The package name convention is to use v as a prefix for the version number and p(patch) as a separator. We use this nomenclature due to a few restrictions in the Go package name convention:

  1. We cannot use . because it's interpreted by the language, think of v1.20.CallFunction.
  2. We cannot use _ because golint complains about it. The code is actually valid, but it looks probably more weird: v1_20.CallFunction.

For instance, if you want to modify a type that was available in the version 1.21 of the API but it will have different fields in the version 1.22, you want to create a new package under api/types/versions/v1p21.