Skip to content

Changelog

The NextPDF ecosystem spans many packages and repositories. This page shows how the ecosystem records change and where each package keeps its own changelog. Use it as an index and a conventions reference, not as a restatement of every commit. Each package keeps its authoritative released changelog in its own repository. The summary table aggregates only the category of change per released version, derived from each repository’s Conventional Commits history.

As a documentation index, this page does not make behavioral claims about any package. To see the rules each package follows when it writes commits and cuts releases, see Changelog conventions.

Every public NextPDF repository follows two contracts:

  • Conventional Commits 1.0.0 — each commit subject uses the form type(scope): description, where type is one of feat, fix, perf, refactor, docs, test, build, ci, chore, or revert. A ! after the type/scope, or a BREAKING CHANGE: footer, marks an incompatible change. Security-relevant fixes are tagged so you can filter them.
  • Semantic Versioning 2.0.0 — a feat raises the minor version, a fix/perf raises the patch version, and a breaking change raises the major version. The released CHANGELOG.md in each repository groups human-readable entries by version, using the Keep a Changelog sections.

The summary below covers only user-facing categories: feat (new capability), fix (corrected behavior), perf (performance), security (security-relevant fix), and breaking changes. Internal-only commit types (docs, test, ci, chore, refactor) are left out of the cross-repo summary on purpose. They do not change what you observe when you use the package.

The authoritative prose changelog for a package is the CHANGELOG.md in that package’s own repository, grouped by released version. For the full entry text, use the repository’s release page or its CHANGELOG.md. This index does not duplicate that text.

PackageRepositoryAuthoritative changelog
nextpdf/corenextpdfCHANGELOG.md (Keep a Changelog)
nextpdf/servernextpdf-serverCHANGELOG.md
nextpdf/laravelnextpdf-LaravelCHANGELOG.md
nextpdf/symfonynextpdf-SymfonyCHANGELOG.md
nextpdf/codeigniternextpdf-CodeIgniterCHANGELOG.md
nextpdf/artisannextpdf-ArtisanCHANGELOG.md
nextpdf/gotenbergnextpdf-GotenbergCHANGELOG.md
nextpdf/cloudflarenextpdf-CloudflareCHANGELOG.md
nextpdf/compat-legacynextpdf-compat-tcpdfCHANGELOG.md
nextpdf (Python bindings)nextpdf-pythonCHANGELOG.md

Cross-repo summary — categories per latest released version

Section titled “Cross-repo summary — categories per latest released version”

This read-only table is generated from each repository’s Conventional Commits history at its latest released tag. It counts the user-facing categories and reports only category counts — never raw commit subjects — so it does not surface internal identifiers, branch names, or planning references. For the prose detail behind any line, follow the package’s own CHANGELOG.md.

PackageLatest releasedNew capability (feat)Fixes (fix)Performance (perf)SecurityBreaking
nextpdf/corev5.2.031729011yes
nextpdf/serverv0.1.0151600no
nextpdf/laravelv0.1.01800no
nextpdf/symfonyv0.1.01700no
nextpdf/codeigniterv0.1.011000no
nextpdf/artisanv0.1.01700no
nextpdf/gotenbergv0.1.00600no
nextpdf/cloudflarev0.1.00800no
nextpdf/compat-legacyv0.1.01800no
nextpdf (Python)v1.1.07500no

The counts are cumulative through the named tag. For each integration package, the first tagged release includes its full pre-1.0 history. The nextpdf/core “Breaking” cell reads yes because the core engine has shipped breaking major versions. The per-version details and migration path for each one live in the core repository’s CHANGELOG.md and its migration/ guides. This index does not restate them.

To keep the public changelog free of internal leakage, this index never surfaces any of the following:

  • raw commit subjects or bodies;
  • internal issue, ticket, cycle, wave, or work-item identifiers;
  • private branch names or unreleased work in progress;
  • roadmap or unannounced features;
  • contributor automation attribution.

A change appears here only after it becomes part of a released, tagged version of a public package. Unreleased work does not appear.