From b16b7aaf0b0a16a8a8de033880bceedb0331d2ae Mon Sep 17 00:00:00 2001 From: Orkuncakilkaya Date: Sat, 12 Sep 2026 12:55:12 +0300 Subject: [PATCH] chore(release): v0.11.0 --- CHANGELOG.md | 21 +++++++++++++++++++++ VERSION | 2 +- changes/app-set-icon.md | 19 ------------------- 3 files changed, 22 insertions(+), 20 deletions(-) delete mode 100644 changes/app-set-icon.md diff --git a/CHANGELOG.md b/CHANGELOG.md index 89cf8b6f..b69bc19f 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -7,6 +7,27 @@ change type. Preview the next one with `ludic dev release --dry-run`. A released section may carry a hand-written summary paragraph above its groups (v0.2.0 has one); the generated bullets below it are not edited by hand. +## v0.11.0 — 2026-09-12 + +### Features + +- **`App.set_icon(path)`** — an icon for a binary that has no bundle to take one from. + + `ludic bundle` builds an `AppIcon.icns` and macOS reads it from the `.app`, so a + shipped game has an icon. `ludic build` produces a bare executable, which has no + bundle, no `CFBundleIconFile` and therefore no icon at all — macOS draws the generic + green "exec" tile in the Dock. That is the build a developer runs all day and the one + they see every session, so "my game has no icon" is true long before it ships. + + ```ludic + App.set_icon("assets/app/icon.png") + ``` + + The path resolves through the pack first and the filesystem second, like every other + asset, so the same call works packed and unpacked — it does not repeat `Audio.load`'s + trick of taking a filesystem path only. An image that cannot be found or decoded + leaves the current icon alone rather than clearing it, calling it in a bundled app is + a harmless no-op, and a headless build compiles it away to nothing. ## v0.10.1 — 2026-09-11 ### Fixes diff --git a/VERSION b/VERSION index 57121573..d9df1bbc 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.10.1 +0.11.0 diff --git a/changes/app-set-icon.md b/changes/app-set-icon.md deleted file mode 100644 index f5031ba3..00000000 --- a/changes/app-set-icon.md +++ /dev/null @@ -1,19 +0,0 @@ -bump: minor -type: feat -**`App.set_icon(path)`** — an icon for a binary that has no bundle to take one from. - -`ludic bundle` builds an `AppIcon.icns` and macOS reads it from the `.app`, so a -shipped game has an icon. `ludic build` produces a bare executable, which has no -bundle, no `CFBundleIconFile` and therefore no icon at all — macOS draws the generic -green "exec" tile in the Dock. That is the build a developer runs all day and the one -they see every session, so "my game has no icon" is true long before it ships. - -```ludic -App.set_icon("assets/app/icon.png") -``` - -The path resolves through the pack first and the filesystem second, like every other -asset, so the same call works packed and unpacked — it does not repeat `Audio.load`'s -trick of taking a filesystem path only. An image that cannot be found or decoded -leaves the current icon alone rather than clearing it, calling it in a bundled app is -a harmless no-op, and a headless build compiles it away to nothing.