Reword readme and upgrade docs

Author: Jean85

README.md

@@ -11,9 +11,7 @@ Symfony integration for [Sentry](https://getsentry.com/).
 
 ## Notice 3.0
 > The current master branch contains the 3.0 version of this bundle, which is currently under development. This version
-> will support the newest 2.0 version of the underlying Sentry SDK version.
->
-> A beta version will be tagged as soon as possible, in the meantime you can continue to use the previous versions.
+> will support the newest 2.0 version of the underlying Sentry SDK version. A beta version is already available.
 > 
 > To know more about the progress of this version see [the relative milestone](https://github.com/getsentry/sentry-symfony/milestone/3)
 
@@ -22,22 +20,20 @@ Symfony integration for [Sentry](https://getsentry.com/).
 Use sentry-symfony for:
 
  * A fast sentry setup
- * Access to the `sentry.client` through the container
+ * Easy configuration in your Symfony app
  * Automatic wiring in your app. Each event has the following things added automatically to it:
    - user
    - Symfony environment
    - app path
-   - hostname
    - excluded paths (cache and vendor)
 
-
 ## Installation
 
 ### Step 1: Download the Bundle
 You can install this bundle using Composer: 
 
 ```bash
-composer require sentry/sentry-symfony:^3.0
+composer require sentry/sentry-symfony:^3.0-beta2
 ```
 
 #### Optional: use custom HTTP factory/transport
@@ -87,12 +83,13 @@ class AppKernel extends Kernel
     // ...
 }
 ```
-Note that, unlike before in version 3, the bundle will be enabled in all environments.
+Note that, unlike before in version 3, the bundle will be enabled in all environments; event reporting, instead, is enabled
+only when providing a DSN (see the next step).
 
 ### Step 3: Configure the SDK
 
-Add your [Sentry DSN](https://docs.sentry.io/quickstart/#configure-the-dsn) value of your project to ``app/config/config.yml``.
-Leaving this value empty will effectively disable Sentry reporting.
+Add your [Sentry DSN](https://docs.sentry.io/quickstart/#configure-the-dsn) value of your project to ``app/config/config_prod.yml``.
+Leaving this value empty (or undeclared) in other environments will effectively disable Sentry reporting.
 
 ```yaml
 sentry:
@@ -112,9 +109,11 @@ TODO
 ## Customization
 
 The Sentry 2.0 SDK uses the Unified API, hence it uses the concept of `Scope`s to hold information about the current 
-state of the app, and attach it to any event that is reported. This bundle has two listeners (`RequestListener` and 
-`ConsoleListener`) that adds some easy default information. Those listeners normally are executed with a priority of `1`
-to allow easier customization with custom listener, that by default run with a lower priority of `0`.
+state of the app, and attach it to any event that is reported. This bundle has three listeners (`RequestListener`, 
+`SubRequestListener` and `ConsoleListener`) that adds some easy default information. 
+
+Those listeners normally are executed with a priority of `1` to allow easier customization with custom listener, that by 
+default run with a lower priority of `0`.
 
 Those listeners are `final` so not extendable, but you can look at those to know how to add more information to the 
 current `Scope` and enrich you Sentry events.

UPGRADE-3.0.md

@@ -31,13 +31,13 @@ changed:
 
  * All services are now private; declare public aliases to access them if needed; you can still use the Sentry SDK global
    functions if you want just to capture messages manually without injecting Sentry services in your code
- * All services uses the full qualified name of the interfaces to name them
- * The `ExceptionListener` has been splitted in two: `RequestListener` and `ConsoleListener`
+ * All services uses the full qualified name of their interfaces to name them
+ * The `ExceptionListener` has been splitted and renamed: we now have a simpler `ErrorListener`, and three other listeners
+ dedicated to enriching events of data (`RequestListener`, `SubRequestListener` and `ConsoleListener`)
  * The listeners are now `final`; append your own listeners to override their behavior
  * The listeners are registered with a priority of `1`; they will run just before the default priority of `0`, to ease
    the registration of custom listener that will change `Scope` data
  * Configuration options of the bundle are now aligned with the new ones of the 2.0 SDK
- * Listeners are no longer used to capture exceptions, it's all demanded to the error handler
 
 ## New services
 This is a brief description of the services registered by this bundle:
@@ -47,7 +47,7 @@ This is a brief description of the services registered by this bundle:
  * `Sentry\ClientInterface`: this is the proper client; compared to the 1.x SDK version it's a lot more slimmed down,
  since a lot of the stuff has been splitted in separated components, so you probably will not interact with it as much as
  in the past. You also have to remind you that the client is bound to the `Hub`, and has to be changed there if you want 
- to use it automatically in error reporting
+ to use a different one automatically in error reporting
  * `Sentry\ClientBuilderInterface`: this is the factory that builds the client; you can call its methods to change all
  the settings and dependencies that will be injected in the latter created client. You can use this service to obtain more
  customized clients for your needs