Remove all 6.x deprecations on 7.0

Author: alexandre-daubois

.doctor-rst.yaml

@@ -72,10 +72,10 @@ rules:
         min_version: '6.0'
 
     deprecated_directive_major_version:
-        major_version: 6
+        major_version: 7
 
     deprecated_directive_min_version:
-        min_version: '6.0'
+        min_version: '7.0'
 
 exclude_rule_for_file:
     - path: configuration/multiple_kernels.rst

components/console/events.rst

@@ -255,16 +255,6 @@ handle all signals e.g. to do some tasks before terminating the command.
         The :class:`Symfony\\Component\\Console\\SignalRegistry\\SignalMap` class was
         introduced in Symfony 6.4.
 
-.. deprecated:: 6.3
-
-    In Symfony versions previous to 6.3, all signals (except ``SIGUSR1`` and
-    ``SIGUSR2``) would terminate the script by calling ``exit(0)``. Starting
-    from Symfony 6.3, no more signal is automatically calling ``exit(0)``.
-
-.. deprecated:: 6.3
-
-    Not returning a value in ``handleSignal()`` is deprecated since Symfony 6.3.
-
 .. _`reserved exit codes`: https://www.tldp.org/LDP/abs/html/exitcodes.html
 .. _`Signals`: https://en.wikipedia.org/wiki/Signal_(IPC)
 .. _`constants of the PCNTL PHP extension`: https://www.php.net/manual/en/pcntl.constants.php

components/http_foundation.rst

@@ -152,13 +152,10 @@ has some methods to filter the input values:
 
 :method:`Symfony\\Component\\HttpFoundation\\ParameterBag::filter`
     Filters the parameter by using the PHP :phpfunction:`filter_var` function.
-
-    .. deprecated:: 6.3
-
-        Ignoring invalid values when using ``filter()`` is deprecated and will throw
-        a :class:`Symfony\\Component\\HttpKernel\\Exception\\BadRequestHttpException`
-        in Symfony 7.0. You can use the ``FILTER_NULL_ON_FAILURE`` flag to keep
-        ignoring them.
+    If invalid values are found, a
+    :class:`Symfony\\Component\\HttpKernel\\Exception\\BadRequestHttpException`
+    is thrown. The ``FILTER_NULL_ON_FAILURE`` flag can be used to ignore invalid
+    values.
 
 All getters take up to two arguments: the first one is the parameter name
 and the second one is the default value to return if the parameter does not

components/validator/resources.rst

@@ -114,10 +114,6 @@ If you use annotations instead of attributes, it's also required to call
         ->addDefaultDoctrineAnnotationReader() // add this only when using annotations
         ->getValidator();
 
-.. deprecated:: 6.4
-
-    Annotations are deprecated since Symfony 6.4, use attributes instead.
-
 To disable the annotation loader after it was enabled, call
 :method:`Symfony\\Component\\Validator\\ValidatorBuilder::disableAnnotationMapping`.
 

console.rst

@@ -171,12 +171,6 @@ You can optionally define a description, help message and the
     ``setDescription()`` method instead of the attribute to define the command
     description.
 
-.. deprecated:: 6.1
-
-    The static property ``$defaultDescription`` was deprecated in Symfony 6.1.
-    Instead, use the ``#[AsCommand]`` attribute to define the optional command
-    description.
-
 The ``configure()`` method is called automatically at the end of the command
 constructor. If your command defines its own constructor, set the properties
 first and then call to the parent constructor, to make those properties
@@ -238,11 +232,6 @@ If you can't use PHP attributes, register the command as a service and
 :ref:`default services.yaml configuration <service-container-services-load-example>`,
 this is already done for you, thanks to :ref:`autoconfiguration <services-autoconfigure>`.
 
-.. deprecated:: 6.1
-
-    The static property ``$defaultName`` was deprecated in Symfony 6.1.
-    Define your command name with the ``#[AsCommand]`` attribute instead.
-
 Running the Command
 ~~~~~~~~~~~~~~~~~~~
 

contributing/documentation/format.rst

@@ -216,39 +216,39 @@ If you are documenting a brand new feature, a change or a deprecation that's
 been made in Symfony, you should precede your description of the change with
 the corresponding directive and a short description:
 
-For a new feature or a behavior change use the ``.. versionadded:: 6.x``
+For a new feature or a behavior change use the ``.. versionadded:: 7.x``
 directive:
 
 .. code-block:: rst
 
-    .. versionadded:: 6.2
+    .. versionadded:: 7.2
 
-        ... ... ... was introduced in Symfony 6.2.
+        ... ... ... was introduced in Symfony 7.2.
 
 If you are documenting a behavior change, it may be helpful to *briefly*
 describe how the behavior has changed:
 
 .. code-block:: rst
 
-    .. versionadded:: 6.2
+    .. versionadded:: 7.2
 
-       ... ... ... was introduced in Symfony 6.2. Prior to this,
+       ... ... ... was introduced in Symfony 7.2. Prior to this,
        ... ... ... ... ... ... ... ... .
 
-For a deprecation use the ``.. deprecated:: 6.x`` directive:
+For a deprecation use the ``.. deprecated:: 7.x`` directive:
 
 .. code-block:: rst
 
-    .. deprecated:: 6.2
+    .. deprecated:: 7.2
 
-        ... ... ... was deprecated in Symfony 6.2.
+        ... ... ... was deprecated in Symfony 7.2.
 
-Whenever a new major version of Symfony is released (e.g. 6.0, 7.0, etc), a new
+Whenever a new major version of Symfony is released (e.g. 7.0, 8.0, etc), a new
 branch of the documentation is created from the ``x.4`` branch of the previous
 major version. At this point, all the ``versionadded`` and ``deprecated`` tags
 for Symfony versions that have a lower major version will be removed. For
-example, if Symfony 6.0 were released today, 5.0 to 5.4 ``versionadded`` and
-``deprecated`` tags would be removed from the new ``6.0`` branch.
+example, if Symfony 7.0 were released today, 6.0 to 6.4 ``versionadded`` and
+``deprecated`` tags would be removed from the new ``7.0`` branch.
 
 .. _reStructuredText: https://docutils.sourceforge.io/rst.html
 .. _Sphinx: https://www.sphinx-doc.org/

doctrine/events.rst

@@ -15,7 +15,7 @@ There are different ways to listen to these Doctrine events:
 
 * **Lifecycle callbacks**, they are defined as public methods on the entity classes and
   they are called when the events are triggered;
-* **Lifecycle listeners and subscribers**, they are classes with callback
+* **Lifecycle listeners**, they are classes with callback
   methods for one or more events and they are called for all entities;
 * **Entity listeners**, they are similar to lifecycle listeners, but they are
   called only for the entities of a certain class.
@@ -25,7 +25,7 @@ These are the **drawbacks and advantages** of each one:
 * Callbacks have better performance because they only apply to a single entity
   class, but you can't reuse the logic for different entities and they don't
   have access to :doc:`Symfony services </service_container>`;
-* Lifecycle listeners and subscribers can reuse logic among different entities
+* Lifecycle listeners can reuse logic among different entities
   and can access Symfony services but their performance is worse because they
   are called for all entities;
 * Entity listeners have the same advantages of lifecycle listeners and they have
@@ -37,7 +37,7 @@ to learn everything about them.
 
 .. seealso::
 
-    This article covers listeners and subscribers for Doctrine ORM. If you are
+    This article covers listeners for Doctrine ORM. If you are
     using ODM for MongoDB, read the `DoctrineMongoDBBundle documentation`_.
 
 Doctrine Lifecycle Callbacks
@@ -110,11 +110,6 @@ define a callback for the ``prePersist`` Doctrine event:
 Doctrine Lifecycle Listeners
 ----------------------------
 
-.. deprecated:: 6.3
-
-    Lifecycle subscribers are deprecated starting from Symfony 6.3 and will be
-    removed in Symfony 7.0. Use lifecycle listeners instead.
-
 Lifecycle listeners are defined as PHP classes that listen to a single Doctrine
 event on all the application entities. For example, suppose that you want to
 update some search index whenever a new entity is persisted in the database. To
@@ -201,7 +196,7 @@ listener in the Symfony application by creating a new service for it and
                         # this is the only required option for the lifecycle listener tag
                         event: 'postPersist'
 
-                        # listeners can define their priority in case multiple subscribers or listeners are associated
+                        # listeners can define their priority in case listeners are associated
                         # to the same event (default priority = 0; higher numbers = listener is run earlier)
                         priority: 500
 
@@ -219,7 +214,7 @@ listener in the Symfony application by creating a new service for it and
 
                 <!--
                     * 'event' is the only required option that defines the lifecycle listener
-                    * 'priority': used when multiple subscribers or listeners are associated to the same event
+                    * 'priority': used when multiple listeners are associated to the same event
                     *             (default priority = 0; higher numbers = listener is run earlier)
                     * 'connection': restricts the listener to a specific Doctrine connection
                 -->
@@ -248,7 +243,7 @@ listener in the Symfony application by creating a new service for it and
                     // this is the only required option for the lifecycle listener tag
                     'event' => 'postPersist',
 
-                    // listeners can define their priority in case multiple subscribers or listeners are associated
+                    // listeners can define their priority in case multiple listeners are associated
                     // to the same event (default priority = 0; higher numbers = listener is run earlier)
                     'priority' => 500,
 
@@ -262,12 +257,6 @@ listener in the Symfony application by creating a new service for it and
 
     The `AsDoctrineListener`_ attribute was introduced in DoctrineBundle 2.7.2.
 
-.. tip::
-
-    Symfony loads (and instantiates) Doctrine listeners only when the related
-    Doctrine event is actually fired; whereas Doctrine subscribers are always
-    loaded (and instantiated) by Symfony, making them less performant.
-
 .. tip::
 
     The value of the ``connection`` option can also be a
@@ -414,148 +403,6 @@ with the ``doctrine.orm.entity_listener`` tag as follows:
             ;
         };
 
-Doctrine Lifecycle Subscribers
-------------------------------
-
-Lifecycle subscribers are defined as PHP classes that implement the
-``Doctrine\Common\EventSubscriber`` interface and which listen to one or more
-Doctrine events on all the application entities. For example, suppose that you
-want to log all the database activity. To do so, define a subscriber for the
-``postPersist``, ``postRemove`` and ``postUpdate`` Doctrine events::
-
-    // src/EventListener/DatabaseActivitySubscriber.php
-    namespace App\EventListener;
-
-    use App\Entity\Product;
-    use Doctrine\Bundle\DoctrineBundle\EventSubscriber\EventSubscriberInterface;
-    use Doctrine\ORM\Event\PostPersistEventArgs;
-    use Doctrine\ORM\Event\PostRemoveEventArgs;
-    use Doctrine\ORM\Event\PostUpdateEventArgs;
-    use Doctrine\ORM\Events;
-
-    class DatabaseActivitySubscriber implements EventSubscriberInterface
-    {
-        // this method can only return the event names; you cannot define a
-        // custom method name to execute when each event triggers
-        public function getSubscribedEvents(): array
-        {
-            return [
-                Events::postPersist,
-                Events::postRemove,
-                Events::postUpdate,
-            ];
-        }
-
-        // callback methods must be called exactly like the events they listen to;
-        // they receive an argument of type Post*EventArgs, which gives you access
-        // to both the entity object of the event and the entity manager itself
-        public function postPersist(PostPersistEventArgs $args): void
-        {
-            $this->logActivity('persist', $args->getObject());
-        }
-
-        public function postRemove(PostRemoveEventArgs $args): void
-        {
-            $this->logActivity('remove', $args->getObject());
-        }
-
-        public function postUpdate(PostUpdateEventArgs $args): void
-        {
-            $this->logActivity('update', $args->getObject());
-        }
-
-        private function logActivity(string $action, mixed $entity): void
-        {
-            // if this subscriber only applies to certain entity types,
-            // add some code to check the entity type as early as possible
-            if (!$entity instanceof Product) {
-                return;
-            }
-
-            // ... get the entity information and log it somehow
-        }
-    }
-
-.. note::
-
-    In previous Doctrine versions, instead of ``Post*EventArgs`` classes, you had
-    to use ``LifecycleEventArgs``, which was deprecated in Doctrine ORM 2.14.
-
-If you're using the :ref:`default services.yaml configuration <service-container-services-load-example>`
-and DoctrineBundle 2.1 (released May 25, 2020) or newer, this example will already
-work! Otherwise, :ref:`create a service <service-container-creating-service>` for this
-subscriber and :doc:`tag it </service_container/tags>` with ``doctrine.event_subscriber``.
-
-If you need to configure some option of the subscriber (e.g. its priority or
-Doctrine connection to use) you must do that in the manual service configuration:
-
-.. configuration-block::
-
-    .. code-block:: yaml
-
-        # config/services.yaml
-        services:
-            # ...
-
-            App\EventListener\DatabaseActivitySubscriber:
-                tags:
-                    - name: 'doctrine.event_subscriber'
-
-                      # subscribers can define their priority in case multiple subscribers or listeners are associated
-                      # to the same event (default priority = 0; higher numbers = listener is run earlier)
-                      priority: 500
-
-                      # you can also restrict listeners to a specific Doctrine connection
-                      connection: 'default'
-
-    .. code-block:: xml
-
-        <!-- config/services.xml -->
-        <?xml version="1.0" encoding="UTF-8" ?>
-        <container xmlns="http://symfony.com/schema/dic/services"
-            xmlns:doctrine="http://symfony.com/schema/dic/doctrine">
-            <services>
-                <!-- ... -->
-
-                <!--
-                    * 'priority': used when multiple subscribers or listeners are associated to the same event
-                    *             (default priority = 0; higher numbers = listener is run earlier)
-                    * 'connection': restricts the listener to a specific Doctrine connection
-                -->
-                <service id="App\EventListener\DatabaseActivitySubscriber">
-                    <tag name="doctrine.event_subscriber" priority="500" connection="default"/>
-                </service>
-            </services>
-        </container>
-
-    .. code-block:: php
-
-        // config/services.php
-        namespace Symfony\Component\DependencyInjection\Loader\Configurator;
-
-        use App\EventListener\DatabaseActivitySubscriber;
-
-        return static function (ContainerConfigurator $container): void {
-            $services = $container->services();
-
-            $services->set(DatabaseActivitySubscriber::class)
-                ->tag('doctrine.event_subscriber'[
-                    // subscribers can define their priority in case multiple subscribers or listeners are associated
-                    // to the same event (default priority = 0; higher numbers = listener is run earlier)
-                    'priority' => 500,
-
-                    // you can also restrict listeners to a specific Doctrine connection
-                    'connection' => 'default',
-                ])
-            ;
-        };
-
-.. tip::
-
-    Symfony loads (and instantiates) Doctrine subscribers whenever the
-    application executes; whereas Doctrine listeners are only loaded when the
-    related event is actually fired, making them more performant.
-
 .. _`Doctrine`: https://www.doctrine-project.org/
 .. _`lifecycle events`: https://www.doctrine-project.org/projects/doctrine-orm/en/current/reference/events.html#lifecycle-events
 .. _`official docs about Doctrine events`: https://www.doctrine-project.org/projects/doctrine-orm/en/current/reference/events.html

mailer.rst

@@ -581,12 +581,6 @@ Alternatively you can attach contents from a stream by passing it directly to th
         ->addPart(new DataPart(fopen('/path/to/documents/contract.doc', 'r')))
     ;
 
-.. deprecated:: 6.2
-
-    In Symfony versions previous to 6.2, the methods ``attachFromPath()`` and
-    ``attach()`` could be used to add attachments. These methods have been
-    deprecated and replaced with ``addPart()``.
-
 Embedding Images
 ~~~~~~~~~~~~~~~~
 
@@ -628,12 +622,6 @@ images inside the HTML contents::
 
     The support of embedded images as HTML backgrounds was introduced in Symfony 6.1.
 
-.. deprecated:: 6.2
-
-    In Symfony versions previous to 6.2, the methods ``embedFromPath()`` and
-    ``embed()`` could be used to embed images. These methods have been deprecated
-    and replaced with ``addPart()`` together with inline ``DataPart`` objects.
-
 .. _mailer-configure-email-globally:
 
 Configuring Emails Globally
@@ -1561,7 +1549,7 @@ Here's an example of making one available to download::
         {
             $message = (new DraftEmail())
                 ->html($this->renderView(/* ... */))
-                ->attach(/* ... */)
+                ->addPart(/* ... */)
             ;
 
             $response = new Response($message->toString());