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]
Semantische versionering (SemVer)
Bij Semantic Versioning gebruik jeMAJOR.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.
Git-tags en GitHub Releases
Maak eerst een Git-tag en push die naar origin.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
Metpush: 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 inUPGRADE.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 deRemoved-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.