Esta página es hermana de Desarrollo de paquetes Laravel. Para la estrategia de compatibilidad con Laravel/PHP, consulta Gestión de la compatibilidad de versiones de paquetes.
Cómo escribir el CHANGELOG.md
El CHANGELOG es la fuente primaria donde los usuarios consultan «qué cambió, cuándo y en qué versión». Adoptar el formato de Keep a Changelog unifica la estructura de categorías dentro del equipo.Reglas básicas
- Titula cada versión con el formato
## [x.y.z] - YYYY-MM-DD. - Usa
Added / Changed / Deprecated / Removed / Fixed / Security. - Coloca enlaces de comparación al final para poder seguir las diferencias.
- Acumula los cambios aún no publicados en
## [Unreleased].
Versionado semántico (SemVer)
En Semantic Versioning,MAJOR.MINOR.PATCH se usa con estos criterios:
- MAJOR: cambios que rompen la compatibilidad hacia atrás (Breaking changes).
- MINOR: adiciones de funcionalidad manteniendo la compatibilidad hacia atrás.
- PATCH: correcciones de bugs manteniendo la compatibilidad hacia atrás.
Ejemplos de decisión en un paquete Laravel
La compatibilidad con Laravel 13 se trata de forma distinta según el cambio.
Consulta siempre la guía de actualización para conocer los cambios de Laravel. La situación de las releases más recientes puede consultarse en laravel/framework releases. Si algún cambio rompe una API que utiliza tu paquete, replantea tu política de compatibilidad.
Tags de Git y GitHub Releases
Primero crea el tag de Git y hazle push a origin.v2.1.0 y publícalo. Pega en el cuerpo la sección ## [2.1.0] del CHANGELOG.
1
Mergea a main el commit objetivo del release
Con todos los tests en verde, mergea en
main.2
Crea y publica el tag de Git
Crea un tag con el formato
vX.Y.Z y hazle push a origin.3
Publica el GitHub Release
Título: el nombre del tag; cuerpo: la sección correspondiente del CHANGELOG.
Releases automatizados con GitHub Actions
Si usaspush: tags: como disparador, la creación de un tag publica automáticamente el GitHub Release. Con softprops/action-gh-release puedes reutilizar directamente el contenido de CHANGELOG.md como cuerpo.
Con
needs: test en el job release, si los tests fallan, la publicación se detiene. Mantén siempre esa protección, tanto para releases manuales como automáticos.Cómo gestionar los Breaking changes
Diseña los Breaking changes para permitir una migración por fases. Marca primero como deprecado y elimina en el siguiente MAJOR: reducirás el coste de migración de tus usuarios.1. Señala la deprecación en el código
2. Documenta la guía de migración
EnUPGRADE.md o en una página dedicada, describe paso a paso los cambios que esperas que hagan tus usuarios.
3. Deja notas de migración entre versiones MAJOR
Al subir de MAJOR, enlaza mutuamente la secciónRemoved del CHANGELOG con la guía de migración. Así, los usuarios pueden ver de un vistazo «qué se eliminó» y «cómo arreglarlo».
Páginas relacionadas
Desarrollo de paquetes Laravel
Repasa los fundamentos de implementación centrados en los service providers.
Gestión de la compatibilidad de versiones de paquetes
Organiza los criterios de compatibilidad Laravel/PHP y el uso de SemVer.
Probar paquetes Laravel con Orchestra Testbench
Revisa la estrategia y la implementación de pruebas necesarias antes del release.