`ludic help` ended with a section titled "contributing to the toolchain itself", listing bootstrap, reseed, docs-gen and release tasks. None of that is available to someone who installed the language — those tasks need the repository — so the shipped tool was advertising work its user cannot do, in a namespace they have to read past to find `new` and `run`. The tasks move to a second program, dev.ludic -> bin/ludic-dev, built from a checkout and excluded from every release artifact. `ludic` keeps the project and package commands and nothing else; `ludic dev …` now explains where the tasks went instead of failing as an unknown command. What this shook out: the two programs share prelude/build/project/pkg, so the helpers each had accreted in whichever file first needed them — cc(), ensure_ludicc, the string functions, title_case, cmd_version — moved to where both can see them. The argument-shift indirection added for the `dev` namespace is gone with the namespace, so commands read argv directly again. `ludic-dev test` asserts the split rather than trusting it: the staged install must build a project, and `ludic dev build` there must fail while naming ludic-dev. install.sh keeps building older tags, whose bootstrap goes through main.ludic. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| docs-deploy-installer.md | ||
| README.md | ||
| split-dev-cli.md | ||
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, orpatch(SemVer). The release version is bumped by the highest level among the pending changesets (unlessludic-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