Ir al contenido

Convenciones del registro de cambios

Esta página establece el contrato que sigue cada repositorio público de NextPDF al registrar un cambio y publicar una versión. Sirve como referencia de convenciones; no afirma ningún comportamiento del paquete. El texto de cada paquete y cada versión reside en el propio CHANGELOG.md de cada repositorio. Esta página define las reglas comunes para que el resumen del registro de cambios entre repositorios sea coherente y no exponga detalles internos.

El asunto de cada commit usa la forma type(scope): description. El type es uno de los siguientes:

TipoSignificadoVisible para el usuarioEfecto en la versión
featUna capacidad nuevaincremento menor
fixUna corrección de comportamientoincremento de parche
perfUna mejora de rendimiento sin cambios de comportamientoincremento de parche
refactorReestructuración interna sin cambios observablesnoninguno
docsSolo documentaciónnoninguno
testSolo pruebasnoninguno
build / ciSolo compilación o canalizaciónnoninguno
choreMantenimiento, dependencias y herramientasnoninguno
revertRevierte un commit anteriordependedepende

Un cambio incompatible se indica con un ! después del tipo o del ámbito (feat(api)!: …) o con un pie de página BREAKING CHANGE:. Cualquiera de estas formas provoca un incremento de versión mayor según Semantic Versioning. Una corrección relevante para la seguridad se registra de forma que pueda clasificarse en la columna Security del resumen entre repositorios.

El incremento de versión es mecánico. Una versión que contenga cualquier cambio incompatible es una versión mayor. En caso contrario, una versión que contenga cualquier feat es una versión menor. En caso contrario, una versión que contenga cualquier fix o perf es un parche. Los paquetes anteriores a 1.0 pueden incrementar la versión menor ante un cambio incompatible según SemVer §4. El commit conserva el marcador de cambio incompatible para que el resumen sea preciso.

El CHANGELOG.md de cada repositorio sigue Keep a Changelog 1.1.0: las entradas se agrupan por versión publicada en Added, Changed, Deprecated, Removed, Fixed y Security. Una sección [Unreleased] puede contener notas en curso dentro del repositorio, pero el resumen entre repositorios solo cuenta las versiones etiquetadas y publicadas. El trabajo no publicado nunca aparece en el índice público.

Cómo se deriva el resumen entre repositorios (y cómo se mantiene sin filtraciones)

Sección titulada «Cómo se deriva el resumen entre repositorios (y cómo se mantiene sin filtraciones)»

La tabla de resumen del índice del registro de cambios se genera leyendo el historial de Conventional Commits de cada repositorio en su última etiqueta publicada, en modo de solo lectura, y contando categorías. Las reglas de derivación son deliberadamente estrictas para que no se filtre ningún detalle interno:

  1. Recuentos, no contenido. Solo se informa el número de commits por tipo visible para el usuario. No se muestra ningún asunto, cuerpo, pie de página ni hash de commit.
  2. Solo tipos visibles para el usuario. docs, test, ci, chore y refactor se excluyen: no modifican nada observable para un consumidor del paquete.
  3. Solo publicado. Un commit cuenta solo una vez que forma parte de una versión etiquetada de un paquete público.
  4. Sin identificadores. Las referencias internas a incidencias, tickets, ciclos, oleadas o elementos de trabajo que puedan aparecer en un ámbito de commit privado nunca se exponen, porque el texto del ámbito en sí nunca se muestra: solo se lee el tipo.
  5. Sin atribución de automatización. Los avisos de atribución automatizada de colaboradores no se leen ni se muestran.

Por eso el registro de cambios público es un resumen por categorías con enlaces al propio CHANGELOG.md de cada paquete, en lugar de un flujo agregado de commits. El resumen está demostrablemente libre de filtraciones internas por construcción. El texto autorizado permanece en el paquete que lo posee.