Docs: Add release information (#7041)

docs/docs/proxy_mode.rst

@@ -12,6 +12,7 @@ Proxy Mode
 
 Moto can be run as a proxy, intercepting all requests to AWS and mocking them instead.  :raw-html:`<br />`
 Some of the benefits:
+
  - Easy to configure for all SDK's
  - Can be reached by Lambda containers, allowing you to mock service-calls inside a Lambda-function
 
@@ -69,7 +70,7 @@ The `AWS_CA_BUNDLE` needs to point to the location of the CA certificate that co
 You can run `moto_proxy --help` to get the exact location of this certificate, depending on where Moto is installed.
 
 Environment Variables Configuration:
-------------------------------
+-------------------------------------
 
 .. code-block:: bash
 

docs/docs/releases.rst

@@ -0,0 +1,53 @@
+.. _releases:
+
+.. role:: bash(code)
+   :language: bash
+
+.. role:: raw-html(raw)
+    :format: html
+
+================================
+Releases and Upgrade Paths
+================================
+
+
+Release Schedule
+------------------
+
+There is no fixed release schedule, although we try to release a new version every 1 or 2 weeks.
+
+Specific release intervals will be influenced by 1) high-priority bugs, 2) number of new features and 3) maintainer availability.
+
+
+Development Releases
+----------------------
+
+Every commit should result in a development release, marked as `Pre-releases in PyPi <https://pypi.org/project/moto/#history>`_ and with the `latest`-tag `in DockerHub <https://hub.docker.com/r/motoserver/moto/tags>`_.
+
+
+Versioning scheme
+----------------------
+
+Moto follows a `semver` scheme: `major.minor.patch`.
+ - A major releases indicates a breaking change
+ - A minor release indicates a big change, but nothing breaking
+ - A patch release will contain new features and bug fixes
+
+
+Breaking Changes
+-----------------
+
+A full list of all changes in a specific release can be found on Github: https://github.com/getmoto/moto/blob/master/CHANGELOG.md
+
+A overview of the breaking changes between major versions:
+
+For Moto 2.x:
+ - A change in the installation method. Use `pip install moto[service]` to only install the required dependencies for that service, or `pip install moto[all]` to install all (1.x behaviour)
+
+For Moto 3.x:
+ - Removed compatibility with `boto`. Specifically: all `service_deprecated`-decorators were removed.
+ - The class-decorator now resets the state before every test-method (before, the state was global - shared between class-methods).
+ - ECS ARN's now use the new (long) format by default
+
+For Moto 4.x:
+ - Removed decorators `mock_dynamodb2` and `mock_rds2` (they were functionally equivalent with `mock_dynamodb` and `mock_rds` since 3.x)

docs/docs/server_mode.rst

@@ -84,6 +84,7 @@ See the following example:
             in_mem_client = boto3.client("s3")
             buckets = in_mem_client.list_buckets()["Buckets"]
             self.assertEqual([b["Name"] for b in buckets], ["test"])
+
 This example shows it is possible to create state using the TreadedMotoServer, and access that state using the usual decorators.  :raw-html:`<br />`
 Note that the decorators will destroy any resources on start, so make sure to not accidentally destroy any resources created by the ThreadedMotoServer that should be kept.
 
@@ -119,6 +120,10 @@ Example Usage
 
 To use Moto in your tests, pass the `endpoint_url`-parameter to the SDK of your choice.
 
+For some SDK's, this can be configured using the environment variable `AWS_ENDPOINT_URL`. See the official AWS documentation: https://docs.aws.amazon.com/sdkref/latest/guide/feature-ss-endpoints.html
+
+If your SDK does not support this, here are some code samples to set this parameter the old-fashioned way.
+
 In Python:
 
 .. code-block:: python

docs/index.rst

@@ -37,6 +37,7 @@ Additional Resources
    docs/iam
    docs/aws_config
    docs/multi_account
+   docs/releases
 
 .. toctree::
   :hidden: