Skip to main content
Als je een Laravel-package langdurig onderhoudt, richt dan eerst je changelog en releaseprocedure in. Door releasebeheer te systematiseren voorkom je dat breaking changes onopgemerkt blijven en dat releasewerk afhankelijk wordt van één persoon.
Deze pagina is een zusterpagina van Laravel-packages ontwikkelen. Zie voor strategieën rond Laravel/PHP-compatibiliteit Versiecompatibiliteit van packages beheren.

CHANGELOG.md schrijven

De changelog is de primaire bron waarin gebruikers nakijken “wat er wanneer en in welke versie is veranderd”. Als je het formaat van Keep a Changelog aanhoudt, kun je de categorie-indeling binnen je team uniform houden.

Basisregels

  • Gebruik versies als kop in het formaat ## [x.y.z] - YYYY-MM-DD
  • Gebruik Added / Changed / Deprecated / Removed / Fixed / Security
  • Zet compare-links onderaan zodat je de diff kunt volgen
  • Zet nog niet uitgebrachte wijzigingen onder ## [Unreleased]
Gebruik voor releasenotes de betreffende versie uit de changelog ongewijzigd. Door de historie bij één bron te houden, lopen README, GitHub Releases en aankondigingen op sociale media minder snel uit elkaar.

Semantische versionering (SemVer)

Bij Semantic Versioning gebruik je MAJOR.MINOR.PATCH volgens deze criteria:
  • MAJOR: wijzigingen die de achterwaartse compatibiliteit breken (breaking change)
  • MINOR: functietoevoegingen met behoud van achterwaartse compatibiliteit
  • PATCH: bugfixes met behoud van achterwaartse compatibiliteit

Beslisvoorbeelden voor Laravel-packages

Hoe je Laravel 13-ondersteuning behandelt, hangt af van de inhoud van de wijziging. Controleer de upgrade-inhoud van Laravel zelf altijd in de Upgrade Guide. De releasestatus van de nieuwste versie vind je bij laravel/framework releases. Als er breaking changes zitten in de API’s die jouw package gebruikt, moet je je compatibiliteitsbeleid herzien.
Het verhogen van de minimale PHP-vereiste of het verwijderen van publieke API’s is vanuit het perspectief van gebruikers een breaking change. Behandel dit als een MAJOR-release, ook als het samenvalt met werk voor een Laravel-major.

Git-tags en GitHub Releases

Maak eerst een Git-tag en push die naar origin.
Selecteer vervolgens in het releasescherm van GitHub de tag v2.1.0 en publiceer de release. Plak in de beschrijving de sectie ## [2.1.0] uit de changelog.
1

Merge de release-commit naar main

Merge naar main in een staat waarin alle tests slagen.
2

Maak een Git-tag en push die

Maak een tag in het formaat vX.Y.Z en push die naar origin.
3

Publiceer de GitHub Release

Gebruik de tagnaam als titel en het betreffende changelog-item als beschrijving.

Automatische releases met GitHub Actions

Met push: tags: als trigger kun je GitHub Releases automatisch publiceren zodra er een tag wordt aangemaakt. Met softprops/action-gh-release kun je de inhoud van CHANGELOG.md rechtstreeks hergebruiken als beschrijving.
Door needs: test op de release-job te zetten, kun je de publicatie tegenhouden als tests falen. Houd deze gate altijd in stand, of je nu handmatig of automatisch releaset.

Omgaan met breaking changes

Ontwerp breaking changes zo dat gebruikers stapsgewijs kunnen migreren. Door iets eerst te deprecaten en pas in de volgende MAJOR te verwijderen, verlaag je de migratiekosten voor gebruikers.

1. Maak de deprecatie zichtbaar in de code

2. Documenteer een migratiegids

Beschrijf in UPGRADE.md of op een aparte pagina stap voor stap welke wijzigingen je van gebruikers verwacht.

3. Laat migratienotities achter tussen majorversies

Wanneer je de MAJOR verhoogt, link dan de Removed-sectie van de changelog en de migratiegids naar elkaar. Gebruikers kunnen dan in één keer nagaan “wat er is verwijderd” en “hoe ze het oplossen”.

Gerelateerde pagina’s

Laravel-packages ontwikkelen

Bekijk de basis van een implementatie rond service providers.

Versiecompatibiliteit van packages beheren

Zet de beslissingscriteria voor Laravel/PHP-compatibiliteit en SemVer op een rij.

Laravel-packages testen met Orchestra Testbench

Bekijk de teststrategie en implementatie die je vóór een release nodig hebt.
Laatst gewijzigd op 6 september 2026