Passer au contenu principal
Laravel publie une version majeure chaque année, aux alentours de février/mars. Pour un développeur de package, achever rapidement la prise en charge d’une nouvelle version est à la fois une contribution à l’écosystème et un moyen important d’accroître la fiabilité de son propre package.
Cette page est la sœur de Les bases du développement de packages. Elle suppose une connaissance de base du développement de packages (service providers, structure du composer.json, etc.).

​
Réagir à la montée de version majeure de Laravel

​
Flux de prise en charge

1

Mettre à jour le require du composer.json

Ajoutez la nouvelle version à la plage de dépendances. Si vous conservez le support de versions anciennes, listez-les avec ||.
"require": {
    "php": "^8.2",
    "illuminate/support": "^12.0||^13.0"
}
Une fois la prise en charge de la nouvelle version terminée et le support des anciennes versions abandonné, supprimez les contraintes anciennes.
"require": {
    "php": "^8.3",
    "illuminate/support": "^13.0||^14.0"
}
En dépendant seulement des composants nécessaires comme illuminate/support plutôt que du illuminate/framework complet, vous gardez un arbre de dépendances léger.
2

Exécuter les tests avec la nouvelle version

Exécutez les tests avec la nouvelle version de Laravel en local ou en CI.
composer update
vendor/bin/pest
Si les tests passent, la compatibilité de base est validée. Sinon, corrigez les API modifiées ou les méthodes supprimées.
3

Ajouter la nouvelle version à la matrice de tests GitHub Actions

Ajoutez la nouvelle version de Laravel à la matrice de test CI pour vérifier la compatibilité en continu. Consultez Exemple de configuration de matrice de tests pour les détails.
4

Publier la version prenant en charge la nouvelle version

Taguez et publiez une nouvelle version incluant les modifications du composer.json. Vos utilisateurs pourront alors migrer vers la nouvelle version de Laravel via un simple composer update.

​
S’inspirer des packages officiels

En cas de doute sur la marche à suivre, référez-vous au composer.json des packages officiels Laravel : c’est la source la plus fiable. Ces packages sont maintenus par l’équipe Laravel, prennent en charge les nouvelles versions le plus rapidement, et servent de référence pour la manière d’écrire les contraintes illuminate/*.

​
Mettre à jour la version PHP requise

Une montée de version de Laravel peut aussi élever la version minimale de PHP. Mettez à jour l’exigence PHP dans le composer.json du package en conséquence.
LaravelPHP minimum
Laravel 11PHP 8.2
Laravel 12PHP 8.2
Laravel 13PHP 8.3
Laravel 14PHP 8.4
"require": {
    "php": "^8.2",
    "illuminate/support": "^11.0||^12.0||^13.0"
}

​
Adopter activement de nouvelles fonctionnalités PHP

Si vous voulez utiliser les nouveautés de PHP 8.3+ (constantes typées, nouvelles fonctions aléatoires, etc.), il faut décider de relever le minimum requis. Cette élévation est un changement cassant au sens du versionnage sémantique, il est donc approprié de la faire lors d’une montée en version majeure. 
"require": {
    "php": "^8.3",
    "illuminate/support": "^12.0||^13.0"
}
Élever la version PHP minimale empêche vos utilisateurs sur PHP ancien de mettre à jour le package. Il est important de le signaler à l’avance dans le README et le CHANGELOG.

​
Stratégie de fin de support des anciennes versions

Maintenir indéfiniment les anciennes versions augmente les coûts de maintenance sur le long terme. Définir une politique de support claire et retirer périodiquement le support d’anciennes versions contribue à une gestion saine du package.

​
Quand mettre fin au support

L’approche courante consiste à s’aligner sur les durées de support de Laravel. Laravel offre 18 mois de corrections de bugs et 2 ans de correctifs de sécurité par version. Adopter la même politique dans votre package facilite la compréhension pour les utilisateurs.
CritèreDescription
Fin du support officiel LaravelCesser de prendre en charge une version de Laravel lorsque son support arrive à échéance
UsageQuand les statistiques de téléchargement Packagist montrent peu d’utilisateurs sur l’ancienne version
Frein à l’ajout de fonctionnalitésLorsque le support de l’ancienne version complique l’implémentation de nouveautés

​
Documenter la politique dans le README

Pour que les utilisateurs se fassent une juste idée, indiquez la politique de support dans README.md. 
## Version Compatibility

| Package | Laravel | PHP  |
|---------|---------|------|
| 3.x     | 13.x    | ^8.2 |
| 2.x     | 11.x, 12.x | ^8.2 |
| 1.x     | 10.x    | ^8.1 |

Only the latest major version receives new features.
Security fixes are backported to the previous major version for 12 months.

​
Coûts du maintien des anciennes versions

Continuer à supporter les anciennes versions engendre les coûts suivants :
  • Double correction de bugs — chaque bug doit être corrigé dans plusieurs branches.
  • Multiplication du code de branchement — chaque version demande des implémentations séparées gérées par des conditions.
  • Croissance de la matrice de tests — le temps d’exécution de la CI augmente.
  • Complexification des correctifs de sécurité — les backports vers les anciennes versions doivent être sûrs.
Alors que l’écosystème monte en version, mettre fin correctement au support des anciennes versions incite aussi les utilisateurs à migrer vers un environnement récent.

​
Avantages d’une prise en charge précoce

Si la prise en charge est achevée en même temps que la sortie de Laravel, vos utilisateurs peuvent migrer immédiatement. C’est un signal fort de fiabilité du package.

​
Vérifier en amont sur les versions de développement

Laravel ne publie pas de beta/RC ; en revanche, vous pouvez installer la version en cours de développement en spécifiant dev-master ou @dev. Vérifier le fonctionnement avant la release majeure permet une prise en charge « jour zéro ». 
# Installer la prochaine version via dev-master
composer require laravel/framework:dev-master --no-update
composer update
vendor/bin/pest
Ou installer avec la contrainte @dev. 
composer require laravel/framework:^14.0@dev --no-update
composer update
vendor/bin/pest
En passant minimum-stability à dev, vous permettez à Composer de résoudre les dépendances avec des versions de développement. 
{
    "minimum-stability": "dev",
    "prefer-stable": true
}
Avec prefer-stable: true, si une version stable existe, elle est préférée. Vous pouvez ainsi tester sur les versions de développement tout en garantissant le basculement automatique vers le stable.

​
La première étape peut se limiter à modifier composer.json

Avant même la vérification exhaustive de compatibilité, il suffit de mettre à jour la plage de dépendances du composer.json et de publier pour que les utilisateurs puissent installer le package. 
"illuminate/support": "^12.0||^13.0"
Les petits défauts pourront être corrigés post-release via une version patch. Plutôt que d’attendre une prise en charge parfaite, privilégiez l’installabilité.

​
Comment suivre les annonces de release

Voici comment prendre connaissance rapidement des annonces des nouvelles versions.
SourceContenu
GitHub WatchRecevez des notifications par e-mail via « Watch → Custom → Releases » sur le dépôt. Suivre les autres packages majeurs au-delà de framework est également recommandé
Blog officiel LaravelAnnonces des releases majeures et présentation des nouveautés
Guide de mise à jour officielListe des changements cassants
Journal de commits laravel/frameworkPour anticiper les changements de la prochaine version, suivre directement les commits

​
Exemple de configuration de matrice de tests

Voici un exemple de workflow GitHub Actions testant automatiquement plusieurs combinaisons de versions Laravel et PHP. 
name: Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      fail-fast: false
      matrix:
        php: [8.2, 8.3, 8.4]
        laravel: ["^12.0", "^13.0"]
        include:
          - laravel: "^13.0"
            testbench: "^10.0"
          - laravel: "^12.0"
            testbench: "^9.0"

    name: PHP ${{ matrix.php }} - Laravel ${{ matrix.laravel }}

    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php }}
          extensions: dom, curl, libxml, mbstring, zip
          coverage: none

      - name: Install dependencies
        run: |
          composer require "laravel/framework:${{ matrix.laravel }}" \
                           "orchestra/testbench:${{ matrix.testbench }}" \
                           --no-interaction --no-update
          composer update --prefer-dist --no-interaction

      - name: Run tests
        run: vendor/bin/pest

​
L’importance de fail-fast: false

Avec fail-fast: false, si une combinaison échoue, les autres combinaisons continuent d’être testées. Vous voyez donc en une seule exécution CI quelles combinaisons posent problème.

​
Mise à jour progressive de la matrice

À la sortie d’une nouvelle version de Laravel, ajoutez-la à la matrice. Quand vous cessez de supporter une ancienne version, retirez-la de la matrice. 
# À ajouter à la sortie de Laravel 14
matrix:
  laravel: ["^13.0", "^14.0"]
  include:
    - laravel: "^14.0"
      testbench: "^11.0"
    - laravel: "^13.0"
      testbench: "^10.0"

​
Exemple de composer.json

Voici un exemple complet de composer.json supportant plusieurs versions. 
{
    "name": "acme/courier",
    "description": "A Laravel courier package",
    "type": "library",
    "license": "MIT",
    "require": {
        "php": "^8.2",
        "illuminate/support": "^12.0||^13.0"
    },
    "require-dev": {
        "orchestra/testbench": "^9.0||^10.0",
        "pestphp/pest": "^3.0",
        "pestphp/pest-plugin-laravel": "^3.0"
    },
    "autoload": {
        "psr-4": {
            "Acme\\Courier\\": "src/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "Acme\\Courier\\Tests\\": "tests/"
        }
    },
    "extra": {
        "laravel": {
            "providers": [
                "Acme\\Courier\\CourierServiceProvider"
            ]
        }
    },
    "minimum-stability": "stable",
    "prefer-stable": true
}

​
Checklist de prise en charge d’une nouvelle version

  • Vérifier le fonctionnement avec la version de développement (dev-master / @dev)
  • Consulter le guide de mise à jour officiel pour les changements cassants
  • Implémenter la prise en charge en environnement de test
  • Ajouter la nouvelle version à la matrice CI et vérifier
  • Ajouter la nouvelle version aux exigences illuminate/* du composer.json
  • Mettre à jour l’exigence PHP au besoin
  • Mettre à jour orchestra/testbench dans require-dev vers la version compatible
  • Taguer la nouvelle version et la publier sur Packagist
  • Mettre à jour le tableau de compatibilité du README
  • Annoncer la fin de support dans le CHANGELOG/README
  • Supprimer les contraintes de l’ancienne version dans le composer.json
  • Retirer l’ancienne version de la matrice de tests
  • Nettoyer les branchements de code liés à l’ancienne version

​
Pages associées

Les bases du développement de packages

Découvrez comment développer un package Laravel autour d’un service provider.

Tests avancés avec Pest

Découvrez comment tester un package avec l’Expectation API de Pest et les datasets.
Dernière modification le 13 juillet 2026

Sujets connexes

CHANGELOG et gestion des releases de packagesUtilisation de la couche de compatibilité SDK officielleÉvénements de cycle de vie de sessionLe nouvel écosystème d'analyse de code Laravel — surveyor / ranger / rosterAnalyse statique de packages (PHPStan / Larastan)