docs: add migrations page.

Author: i0bs

docs/faq.rst

@@ -38,7 +38,7 @@ The short answer is: **yes.**
 
 However, the term "work" is loosely structured here. Imagine it like taping a hole in the wall instead of repairing the wall.
 We're essentially "plastering" support for discord.py instead of doing the surgery on its internal organs to make it work well
-with our library. As it currently stands, **discord-interactions and discord.py** are API wrappers. You will be able to run code
+with our library. As it currently stands, **interactions.py and discord.py** are API wrappers. You will be able to run code
 *alongside* one another, and you will be able to plug in some classes, but the data conversion **must be exact.**
 
 What does that mean? Well, we'll show you:
@@ -99,7 +99,7 @@ it breaking, hence the "plastering" that is going on here.
 
 Where should we go with discord.py being gone?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The most *biased* answer would be to, of course, *use discord-interactions.* We already offer a lot of the integral API wrapper
+The most *biased* answer would be to, of course, *use interactions.py.* We already offer a lot of the integral API wrapper
 aspects as discord.py does, however, we only specialize in interactions. Which means things such as these won't be supported
 officially by us (but might be available as 3rd parties):
 

docs/index.rst

@@ -1,7 +1,7 @@
 .. image:: _static/banner.png
 
-discord-interactions
-====================
+interactions.py
+===============
 Ever since December 2019, this open-source project has become the culmination of dedication and research towards figuring out the best way to bring **interactions from Discord to you:** we are an easy, simple, scalable and modular library for Discord interactions.
 
 - Tired of using numerous module dependencies for slash commands and buttons?
@@ -51,6 +51,7 @@ Please look at our pages below to find out where to go.
    quickstart.rst
    api.rst
    faq.rst
+   migration.rst
 
 How can I contribute?
 *********************
@@ -87,7 +88,7 @@ Advanced Search
 * :ref:`modindex`
 * :ref:`search`
 
-.. _contribution requirements: https://github.com/goverfl0w/discord-interactions/blob/stable/CONTRIBUTING.md
-.. _MIT License: https://github.com/goverfl0w/discord-interactions/blob/stable/LICENSE
-.. _Pull Requests: https://github.com/goverfl0w/discord-interactions/pulls
-.. _Issues: https://github.com/goverfl0w/discord-interactions/issues
+.. _contribution requirements: https://github.com/interactions-py/library/blob/stable/CONTRIBUTING.md
+.. _MIT License: https://github.com/interactions-py/library/blob/stable/LICENSE
+.. _Pull Requests: https://github.com/interactions-py/library/pulls
+.. _Issues: https://github.com/interactions-py/library/issues

docs/migration.rst

@@ -0,0 +1,25 @@
+Migration
+=========
+
+This page aims to serve as a guide towards helping users understand any breaking or otherwise important design choices made
+between versions to guide towards easy migration between one another.
+
+4.0.1 → 4.0.2
+~~~~~~~~~~~~~~~
+
+The biggest major change between these two versions is the way ``HTTPClient`` and modelled API schema objects are used.
+In ``4.0.2``, a new ``_state`` attribute is added in model objects in order to use helper methods. This will not be needed
+if you're working with dispatched events from the Gateway, however, manually generating your own model object for use
+will need it appended as a key-word argument. The example below shows this change:
+
+.. code-block:: python
+
+    # 4.0.1
+    data = await bot.http.get_channel(789032594456576004)
+    channel = interactions.Channel(**data)
+
+    # 4.0.2
+    ...
+    channel = interactions.Channel(**data, _state=bot.http)
+
+This change was added in favor for being able to use endpoints in an abstracted state.