From b39cd1e797ffc1649b770a60d0502b4ce97b0312 Mon Sep 17 00:00:00 2001 From: Nick Dimiduk Date: Fri, 26 Jun 2020 10:27:10 -0700 Subject: [PATCH] HBASE-24644 Add a clause to the book noting that sometimes we short-circuit the deprecation cycle Signed-off-by: Sean Busbey Signed-off-by: Duo Zhang Signed-off-by: Viraj Jasani Signed-off-by: Jan Hentschel --- src/main/asciidoc/_chapters/upgrading.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/src/main/asciidoc/_chapters/upgrading.adoc b/src/main/asciidoc/_chapters/upgrading.adoc index 27d40774cff..c8302f699ac 100644 --- a/src/main/asciidoc/_chapters/upgrading.adoc +++ b/src/main/asciidoc/_chapters/upgrading.adoc @@ -69,6 +69,7 @@ In addition to the usual API versioning considerations HBase has other compatibi * Allow changing or removing existing client APIs. * An API needs to be deprecated for a whole major version before we will change/remove it. ** An example: An API was deprecated in 2.0.1 and will be marked for deletion in 4.0.0. On the other hand, an API deprecated in 2.0.0 can be removed in 3.0.0. +** Occasionally mistakes are made and internal classes are marked with a higher access level than they should. In these rare circumstances, we will accelerate the deprecation schedule to the next major version (i.e., deprecated in 2.2.x, marked `IA.Private` 3.0.0). Such changes are communicated and explained via release note in Jira. * APIs available in a patch version will be available in all later patch versions. However, new APIs may be added which will not be available in earlier patch versions. * New APIs introduced in a patch version will only be added in a source compatible way footnote:[See 'Source Compatibility' https://blogs.oracle.com/darcy/entry/kinds_of_compatibility]: i.e. code that implements public APIs will continue to compile. ** Example: A user using a newly deprecated API does not need to modify application code with HBase API calls until the next major version.