ludic/changes
Orkuncakilkaya 470971bf70
All checks were successful
bootstrap / cfree-fixpoint (push) Successful in 22s
ci / build-and-test (push) Successful in 3m0s
commit-lint / conventional-commits (push) Successful in 2s
docs / build-and-deploy (push) Successful in 33s
fix(install): keep the package store across an upgrade
The install root is not only the artifact: `ludic add` caches fetched packages
in <root>/store, keyed by content hash. install_staged moved the whole root
aside and replaced it, so re-running the installer — which is exactly what
`ludic upgrade` does — deleted the cache and forced every project to refetch.

The store is moved into the staged tree before the swap. Nothing else in the
root is preserved, because everything else is the toolchain and should be
replaced.

Verified by staging an install, planting a store entry, upgrading, and reading
the entry back.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-05 23:40:05 +03:00
..
installer-keeps-store.md fix(install): keep the package store across an upgrade 2026-09-05 23:40:05 +03:00
README.md refactor(cli)!: split the contributor tool out of the ludic CLI 2026-09-05 23:15:12 +03:00

Changesets

A changeset is one small Markdown file describing a single user-facing change, dropped in this directory. ludic-dev release consumes every changeset here into a new CHANGELOG.md section, bumps VERSION, and deletes the consumed files.

Format

bump: minor
type: feat
One or more lines describing the change, in the past-agnostic imperative used in
the changelog. Markdown is fine.
  • bump: — major, minor, or patch (SemVer). The release version is bumped by the highest level among the pending changesets (unless ludic-dev release <level> overrides it).
  • type: — the Conventional Commit type (feat, fix, perf, docs, …). It decides which group the change lands in: feat → Features, fix → Fixes, perf → Performance, and so on, in that order. A type with no known heading gets one named after itself.

Writing the body

The body is markdown and reaches the changelog as markdown: it becomes one list item, with continuation lines indented to stay inside it. Nested bullets, blank lines between paragraphs and inline code all survive.

bump: minor
type: feat
**Tiled map support** — load and draw Tiled maps.

- **TMX/TSX** — the XML formats, decoded to the same intermediate as JSON.
- **Collision** — the `collision` layer projects onto the engine tilemap.

Lead with the thing that changed, not with the mechanism. A reader scanning the release should be able to stop after your first clause.

Adding one

Create a file with a short, unique name, e.g. changes/regex-namespace.md. Any filename works except this README.md, which the release step always skips.

Preview how the next release will read before cutting it — this writes nothing:

ludic-dev release --dry-run