Merge remote-tracking branch 'origin/3.7.x' into 4.3.x

* origin/3.7.x: (25 commits)
  Bump doctrine/.github/.github/workflows/composer-lint.yml (#558)
  Bump doctrine/.github/.github/workflows/release-on-milestone-closed.yml
  Bump doctrine/.github/.github/workflows/coding-standards.yml
  Bump doctrine/.github/.github/workflows/phpstan.yml
  Bump actions/checkout from 5 to 6 (#551)
  Bump doctrine/.github/.github/workflows/composer-lint.yml
  Bump doctrine/.github/.github/workflows/release-on-milestone-closed.yml
  Bump doctrine/.github/.github/workflows/phpstan.yml
  Bump doctrine/.github/.github/workflows/coding-standards.yml
  Update phpstan/phpstan requirement from 2.1.31 to 2.1.32 (#547)
  Bump doctrine/.github/.github/workflows/coding-standards.yml (#543)
  Bump doctrine/.github/.github/workflows/release-on-milestone-closed.yml (#544)
  Bump doctrine/.github/.github/workflows/phpstan.yml (#546)
  Bump doctrine/.github/.github/workflows/composer-lint.yml (#545)
  Bump actions/download-artifact from 5 to 6 (#538)
  Bump doctrine/.github from 12.0.0 to 12.1.0 (#539)
  Bump actions/upload-artifact from 4 to 5 (#540)
  Bump doctrine/.github from 10.1.0 to 12.0.0
  Fix conflict
  Docs review
  ...

.github/workflows/coding-standards.yml

@@ -12,4 +12,4 @@ on:
 jobs:
   coding-standards:
     name: "Coding Standards"
-    uses: "doctrine/.github/.github/workflows/coding-standards.yml@8.0.0"
+    uses: "doctrine/.github/.github/workflows/coding-standards.yml@13.1.0"

.github/workflows/composer-lint.yml

@@ -17,4 +17,4 @@ on:
 jobs:
   composer-lint:
     name: "Composer Lint"
-    uses: "doctrine/.github/.github/workflows/composer-lint.yml@8.0.0"
+    uses: "doctrine/.github/.github/workflows/composer-lint.yml@13.1.0"

.github/workflows/continuous-integration.yml

@@ -39,7 +39,7 @@ jobs:
 
     steps:
       - name: "Checkout"
-        uses: "actions/checkout@v5"
+        uses: "actions/checkout@v6"
         with:
           fetch-depth: 2
 
@@ -68,7 +68,7 @@ jobs:
         run: "vendor/bin/phpunit --coverage-clover=coverage.xml"
 
       - name: "Upload coverage file"
-        uses: "actions/upload-artifact@v4"
+        uses: "actions/upload-artifact@v5"
         with:
           name: "phpunit-${{ matrix.dependencies }}-${{ matrix.stability }}-${{ matrix.php-version }}.coverage"
           path: "coverage.xml"
@@ -81,12 +81,12 @@ jobs:
 
     steps:
       - name: "Checkout"
-        uses: "actions/checkout@v5"
+        uses: "actions/checkout@v6"
         with:
           fetch-depth: 2
 
       - name: "Download coverage files"
-        uses: "actions/download-artifact@v5"
+        uses: "actions/download-artifact@v6"
         with:
           path: "reports"
 

.github/workflows/release-on-milestone-closed.yml

@@ -8,7 +8,7 @@ on:
 jobs:
   release:
     name: "Git tag, release & create merge-up PR"
-    uses: "doctrine/.github/.github/workflows/release-on-milestone-closed.yml@8.0.0"
+    uses: "doctrine/.github/.github/workflows/release-on-milestone-closed.yml@13.1.0"
     secrets:
       GIT_AUTHOR_EMAIL: ${{ secrets.GIT_AUTHOR_EMAIL }}
       GIT_AUTHOR_NAME: ${{ secrets.GIT_AUTHOR_NAME }}

.github/workflows/static-analysis.yml

@@ -11,4 +11,4 @@ on:
 
 jobs:
   static-analysis:
-    uses: "doctrine/.github/.github/workflows/phpstan.yml@8.0.0"
+    uses: "doctrine/.github/.github/workflows/phpstan.yml@13.1.0"

README.markdown

@@ -1,7 +1,7 @@
 DoctrineFixturesBundle
 ======================
 
-This bundle integrates the [Doctrine2 Data Fixtures library](https://github.com/doctrine/data-fixtures)
-into Symfony so that you can load data fixtures programmatically into the Doctrine ORM or ODM.
+This bundle integrates the [Doctrine Data Fixtures library](https://github.com/doctrine/data-fixtures)
+into Symfony so that you can load data fixtures programmatically into the Doctrine ORM.
 
 Read the full [documentation of this bundle](http://symfony.com/doc/current/bundles/DoctrineFixturesBundle/index.html).

docs/index.rst

@@ -1,9 +1,8 @@
 DoctrineFixturesBundle
 ======================
 
-Fixtures are used to load a "fake" set of data into a database that can then
-be used for testing or to help give you some interesting data while you're
-developing your application.
+Fixtures are used to load a sample set of data into a database that can then
+be used for testing or to provide useful data while you're developing your application.
 
 This bundle is compatible with any database supported by `Doctrine ORM`_
 (MySQL, PostgreSQL, SQLite, etc.). If you are using MongoDB, you must use
@@ -30,8 +29,8 @@ Writing Fixtures
 Data fixtures are PHP classes where you create objects and persist them to the
 database.
 
-Imagine that you want to add some ``Product`` objects to your database. No problem!
-Create a fixtures class and start adding products::
+Imagine that you want to add some ``Product`` objects to your database. To do this,
+create a fixtures class and start adding products::
 
     // src/DataFixtures/AppFixtures.php
     namespace App\DataFixtures;
@@ -44,7 +43,7 @@ Create a fixtures class and start adding products::
     {
         public function load(ObjectManager $manager): void
         {
-            // create 20 products! Bam!
+            // create 20 products with random prices
             for ($i = 0; $i < 20; $i++) {
                 $product = new Product();
                 $product->setName('product '.$i);
@@ -86,7 +85,7 @@ Accessing Services from the Fixtures
 ------------------------------------
 
 In some cases, you may need to access your application's services inside a fixtures
-class. No problem! Your fixtures class is a service, so you can use normal dependency
+class. Your fixtures class is a service, so you can use normal dependency
 injection::
 
     // src/DataFixtures/AppFixtures.php
@@ -120,9 +119,9 @@ injection::
 Splitting Fixtures into Separate Files
 --------------------------------------
 
-In most applications, creating all your fixtures in just one class is fine.
-This class may end up being a bit long, but it's worth it because having one
-file helps keeping things simple.
+In many applications, creating all your fixtures in one class is sufficient.
+This class may become very long, but having a single file can help keep related
+things together.
 
 If you do decide to split your fixtures into separate files, Symfony helps you
 solve the two most common issues: sharing objects between fixtures and loading
@@ -138,7 +137,7 @@ exact same object via its name.
 
 .. note::
 
-    Adding object references only works for ORM entities or ODM documents.
+    Adding object references only works for ORM entities.
 
 .. code-block:: php
 
@@ -176,8 +175,8 @@ exact same object via its name.
         }
     }
 
-The only caveat of using references is that fixtures need to be loaded in a
-certain order (in this example, if the ``Group`` fixtures are loaded before the
+When using references, you must be careful about the order in which the fixtures
+are loaded (in this example, if the ``Group`` fixtures are loaded before the
 ``User`` fixtures, you'll see an error). By default, Doctrine loads the fixture
 files in alphabetical order, but you can control their order as explained in the
 next section.
@@ -283,7 +282,7 @@ fixture using the ``UserFixtures`` group:
 Specifying purging behavior
 ---------------------------
 
-By default all previously existing data is purged using ``DELETE FROM table`` statements. If you prefer to use
+By default, all previously existing data is purged using ``DELETE FROM table`` statements. If you prefer to use
 ``TRUNCATE table`` statements for purging, use ``--purge-with-truncate``.
 
 If you want to exclude a set of tables from being purged, e.g. because your schema comes with pre-populated,
@@ -386,8 +385,8 @@ With the ``--purger`` option we can now specify to use ``my_purger`` instead of
 Loading Fixtures in Dry Run mode
 --------------------------------
 
-The ``--dry-run`` option allows you to simulate the execution of your fixtures 
-and see what would happen if they were executed, without actually applying 
+The ``--dry-run`` option allows you to simulate the execution of your fixtures
+and see what would happen if they were executed, without actually applying
 any changes to the database.
 
 This way, you can inspect the behavior of your fixtures safely, without modifying your database.
@@ -404,7 +403,7 @@ You can also combine ``--dry-run`` with other options such as ``--append`` or ``
 
 .. note::
 
-    When using ``--dry-run`` option, all persisting operations are skipped.  
+    When using ``--dry-run`` option, all persisting operations are skipped.
     The fixtures will be processed, and any logging or output will behave as usual,
     but no database changes will occur.