diff --git a/doc/source/library.rst b/doc/source/library.rst
index 64bd2c2..a89512c 100644
--- a/doc/source/library.rst
+++ b/doc/source/library.rst
@@ -7,15 +7,14 @@
 test suites an interface for reusing pieces of tempest code. Any public
 interface that lives in tempest/lib in the tempest repo is treated as a stable
 public interface and it should be safe to external consume that. Every effort
-goes into maintaining backwards compatibility with any change. Just as with
-tempest-lib the library is self contained and doesn't have any dependency on
-other tempest internals outside of lib. (including no usage of tempest
-configuration)
+goes into maintaining backwards compatibility with any change.
+The library is self contained and doesn't have any dependency on
+other tempest internals outside of lib (including no usage of tempest
+configuration).
 
 Stability
 ---------
-Just as tempest-lib before it any code that lives in tempest/lib will be treated
-as a stable interface, nothing has changed in regards to interface stability.
+Any code that lives in tempest/lib will be treated as a stable interface.
 This means that any public interface under the tempest/lib directory is
 expected to be a stable interface suitable for public consumption. However, for
 any interfaces outside of tempest/lib in the tempest tree (unless otherwise
diff --git a/doc/source/plugin.rst b/doc/source/plugin.rst
index 2622c22..ad26741 100644
--- a/doc/source/plugin.rst
+++ b/doc/source/plugin.rst
@@ -11,13 +11,13 @@
 =================
 
 Creating a plugin is fairly straightforward and doesn't require much additional
-effort on top of creating a test suite using tempest-lib. One thing to note with
+effort on top of creating a test suite using tempest.lib. One thing to note with
 doing this is that the interfaces exposed by tempest are not considered stable
 (with the exception of configuration variables which ever effort goes into
 ensuring backwards compatibility). You should not need to import anything from
 tempest itself except where explicitly noted. If there is an interface from
 tempest that you need to rely on in your plugin it likely needs to be migrated
-to tempest-lib. In that situation, file a bug, push a migration patch, etc. to
+to tempest.lib. In that situation, file a bug, push a migration patch, etc. to
 expedite providing the interface in a reliable manner.
 
 Plugin Cookiecutter
@@ -102,11 +102,6 @@
 Then you need to ensure you locally define all of the methods in the abstract
 class, you can refer to the api doc below for a reference of what that entails.
 
-Also, note eventually this abstract class will likely live in tempest-lib, when
-that migration occurs a deprecation shim will be added to tempest so as to not
-break any existing plugins. But, when that occurs migrating to using tempest-lib
-as the source for the abstract class will be prudent.
-
 Abstract Plugin Class
 ---------------------