Remove obsolete versionadded in 3.4

contributing/community/review-comments.rst

@@ -91,34 +91,34 @@ Don't use hyperbole ("always", "never", "endlessly", "nothing", "worst", "horrib
 **Don't:** *"I don't like how you wrote this code"* - there is no clear explanation why you
 don't like how it's written.
 
-**Better:** *"I find it hard to read this code as there many nested if statements, can you make it more
-readable? By encapsulating some of it's details or maybe adding some comments to explain the overall logic."* -
+**Better:** *"I find it hard to read this code as there is many nested if statements, can you make it more
+readable? By encapsulating some of its details or maybe adding some comments to explain the overall logic."* -
 You explain why you find the code hard to read *and* give some suggestions for improvement.
 
 If a piece of code is in fact wrong, explain why:
 
-* ``This code doesn't comply with Symfony's CS rules. Please see [...] for details``.
+* "This code doesn't comply with Symfony's CS rules. Please see [...] for details."
 
-* ``Symfony 3 still uses PHP 5 and doesn't allow the usage scalar type-hints.``.
+* "Symfony 3 still uses PHP 5 and doesn't allow the usage scalar type-hints."
 
-* ``I think the code is less readable now`` - careful here, be sure explain why you think
+* "I think the code is less readable now." - careful here, be sure explain why you think
   the code is less readable, and maybe give some suggestions?
 
 **Examples of valid reasons to reject:**
 
-    * We tried that in the past (link to the relevant PR) but we needed to revert it for XXX reason.
+* "We tried that in the past (link to the relevant PR) but we needed to revert it for XXX reason."
 
-    * That change would introduce too many merge conflicts when merging up Symfony branches.
-      In the past we've always rejected changes like this.
+* "That change would introduce too many merge conflicts when merging up Symfony branches.
+  In the past we've always rejected changes like this."
 
-    * I profiled this change and it hurts performance significantly (if you don't profile, it's an opinion, so we can ignore)
+* "I profiled this change and it hurts performance significantly" - if you don't profile, it's an opinion, so we can ignore
 
-    * Code doesn't match Symfony's CS rules (e.g. use ``[]`` instead of ``array()``)
+* "Code doesn't match Symfony's CS rules (e.g. use ``[]`` instead of ``array()``)"
 
-    * We only provide integration with very popular projects (e.g. we integrate Bootstrap but not your own CSS framework)
+* "We only provide integration with very popular projects (e.g. we integrate Bootstrap but not your own CSS framework)"
 
-    * This would require adding lots of code and making lots of changes for a feature that doesn't look so important.
-      That could hurt maintaining in the future.
+* "This would require adding lots of code and making lots of changes for a feature that doesn't look so important.
+  That could hurt maintaining in the future."
 
 Asking for Changes
 ------------------

contributing/documentation/format.rst

@@ -173,32 +173,30 @@ New Features or Behavior Changes
 
 If you're documenting a brand new feature or a change that's been made in
 Symfony, you should precede your description of the change with a
-``.. versionadded:: 2.X`` directive and a short description:
+``.. versionadded:: 3.x`` directive and a short description:
 
 .. code-block:: rst
 
-    .. versionadded:: 2.7
+    .. versionadded:: 3.4
 
-        The ``askHiddenResponse()`` method was introduced in Symfony 2.7.
-
-    You can also ask a question and hide the response. This is particularly [...]
+        The special ``!`` template prefix was introduced in Symfony 3.4.
 
 If you're documenting a behavior change, it may be helpful to *briefly* describe
 how the behavior has changed:
 
 .. code-block:: rst
 
-    .. versionadded:: 2.7
+    .. versionadded:: 3.4
 
-        The ``include()`` function is a new Twig feature that's available in
-        Symfony 2.7. Prior, the ``{% include %}`` tag was used.
+        Support for annotation routing without an external bundle was added in
+        Symfony 3.4. Prior, you needed to install the SensioFrameworkExtraBundle.
 
-Whenever a new minor version of Symfony is released (e.g. 2.4, 2.5, etc),
+Whenever a new major version of Symfony is released (e.g. 3.0, 4.0, etc),
 a new branch of the documentation is created from the ``master`` branch.
 At this point, all the ``versionadded`` tags for Symfony versions that have
-reached end-of-maintenance will be removed. For example, if Symfony 2.5 were
-released today, and 2.2 had recently reached its end-of-maintenance, the 2.2
-``versionadded`` tags would be removed from the new ``2.5`` branch.
+a lower major version will be removed. For example, if Symfony 4.0 were
+released today, 3.0 to 3.4 ``versionadded`` tags would be removed from the new
+``4.0`` branch.
 
 .. _reStructuredText: http://docutils.sourceforge.net/rst.html
 .. _Sphinx: http://sphinx-doc.org/

controller/argument_value_resolver.rst

@@ -15,11 +15,7 @@ functionality.
 Functionality Shipped with the HttpKernel
 -----------------------------------------
 
-.. versionadded:: 3.3
-
-    The ``SessionValueResolver`` and ``ServiceValueResolver`` were both added in Symfony 3.3.
-
-Symfony ships with five value resolvers in the HttpKernel component:
+Symfony ships with the following value resolvers in the HttpKernel component:
 
 :class:`Symfony\\Component\\HttpKernel\\Controller\\ArgumentResolver\\RequestAttributeValueResolver`
     Attempts to find a request attribute that matches the name of the argument.
@@ -46,11 +42,6 @@ Symfony ships with five value resolvers in the HttpKernel component:
     argument list. When the action is called, the last (variadic) argument will
     contain all the values of this array.
 
-.. note::
-
-    Prior to Symfony 3.1, this logic was resolved within the ``ControllerResolver``.
-    The old functionality is rewritten to the aforementioned value resolvers.
-
 Adding a Custom Value Resolver
 ------------------------------
 

workflow/usage.rst

@@ -413,7 +413,7 @@ of domain logic in your templates:
 
 The following example shows these functions in action:
 
-.. code-block:: twig
+.. code-block:: html+twig
 
     <h3>Actions</h3>
     {% if workflow_can(post, 'publish') %}