mirror of https://github.com/ceph/go-ceph
docs: add a API stability document
Signed-off-by: Sven Anderson <sven@redhat.com>
This commit is contained in:
parent
cdbffdc229
commit
83c0acf52c
|
@ -0,0 +1,41 @@
|
|||
# API stability
|
||||
|
||||
This library offers Go API bindings for ceph libraries and interfaces. In order
|
||||
to provide a stable exported API and at the same time be able to get early
|
||||
feedback for new and possibly immature API designs, we maintain three levels of
|
||||
API stablity:
|
||||
|
||||
## Stable
|
||||
|
||||
This is the default level. Everything that is exported and not annotated
|
||||
otherwise is considered stable. As long as we release 0.x versions, this is
|
||||
still no 100% guarantee, but we try to avoid breaking changes as much as
|
||||
possible. Once we reached version 1.x, this level provides a guarantee that no
|
||||
breaking changes will be introduced until the next major release, as it is
|
||||
convention in the Go community.
|
||||
|
||||
## Deprecated
|
||||
|
||||
This is a level for APIs that should not be used for new code. These are marked
|
||||
with _DEPRECATED_ in the documentation. During 0.x releases these APIs might get
|
||||
removed in a future release, especially the 1.0 release, so we recommend
|
||||
refactoring the code at the earliest convenience. After the 1.0 release,
|
||||
deprecated APIs will not be removed, however they are still deprecated and only
|
||||
in maintanence mode. We usually don't make improvements for these APIs and we
|
||||
can't guarantee optimal performance.
|
||||
|
||||
## Preview
|
||||
|
||||
This is a level for APIs that are fresh and might need further refinements in
|
||||
following releases. These are marked with _PREVIEW_ in the documentation and are
|
||||
only available, if the build tag `ceph_preview` is set. There might be breaking
|
||||
changes in future releases regarding preview APIs. Usually new exported APIs are
|
||||
introduced with this level first and become stable when there were no major
|
||||
changes to the API for two releases. The schedule for preview APIs becoming
|
||||
stable is tracked in a separate document (link TBD).
|
||||
|
||||
Please note that while these APIs are still considered "unstable", this is not
|
||||
true for the quality of their implementations, which we regard as stable and
|
||||
error free, at least with the quality of beta code. Therefore we highly
|
||||
encourage the use of these APIs and providing feedback to us, if a possible
|
||||
breaking change in the API in future releases is feasible for your project.
|
Loading…
Reference in New Issue