Orkuncakilkaya
cf814d4a97
A pack root is packed wholesale, and that is the right default - a game writes `pack "assets"` and everything it opens is in the pack. What also goes in is everything the game does NOT open: the preview renders a model pipeline leaves beside its meshes, the intermediate a texture bake writes and never reads again, the .blend the .gltf came out of. Nothing errors, nothing looks wrong, and the app is simply bigger than the game. The only way out the manifest offered was naming every file by hand, which is worse - a list that goes stale the day someone adds a texture. So `.packignore`, with gitignore's rules, because that is the file everyone already knows. Anchored and floating patterns, `preview/` for directories only, `*` and `?` stopping at a separator where `**` crosses one, `[a-z]` classes, `!` re-includes with the last line winning, a deeper file beating a shallower one, and no re-including out of an ignored directory. The semantics are not claimed, they are checked: the implementation was diffed against git itself over two fixtures - 35 paths, 19 patterns, nested ignore files, directory negation, `[!0-9]` and `\#` escaping - and `git check-ignore` and `ludic pack` agree on every path. Two rules of its own, because a pack is not a working tree. `.packignore` is never packed (nothing reads one at run time, and --no-ignore does not bring it back). And it governs the project's own roots only: a package's resources - the renderer's shaders above all - are added after the gather, so a stray `*.frag` in a game's ignore file cannot quietly un-ship what it needs to draw anything. `ludic pack` reports what it left out; `--no-ignore` packs everything so you can see what a rule is costing. `ludic bundle` gathers through the same path, so the two agree by construction. |
||
|---|---|---|
| .. | ||
| packignore.md | ||
| README.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