@oakoss/oakum 0.1.0 → 0.1.1

package/CHANGELOG.md

@@ -0,0 +1,9 @@
+# Changelog
+
+## 0.1.1 (2026-09-01)
+
+### Fixed
+
+Self-host release CI uploads cargo-dist artifacts into the GitHub Release oakum already created, instead of calling create again.
+
+Generated by oakum 0.1.0.

package/README.md

@@ -18,7 +18,7 @@ Oakum derives which is which — from the binary targets Cargo resolves for a pa
 
 **Config expresses preference; facts are derived.** What depends on what, what is publishable, what needs a bump, and which artifact ships are all read from the repository on every run. Templates, titles, the tag format oakum writes, and commit messages are yours, because they describe output rather than the repository, so they cannot go stale. Two keys are neither: `tool-version`, which pins the binary allowed to run, and `resolves-dependencies-at`, which states when your package manager fixes a dependency — a fact about the ecosystem that oakum cannot read from your repository. `init` and `upgrade` will write `_schema.json` next to `_config.toml` and a `#:schema ./_schema.json` line; that directive is taplo's, not part of TOML, so editor support varies.
 
-**Every command writes only the files it owns.** Oakum does not install git hooks, touch git config, edit `AGENTS.md`, write CI workflows, or create commits you did not ask for. `version` owns the manifests it bumps and the lockfile entries those bumps invalidate — a Cargo version bump invalidates `Cargo.lock`, so leaving it stale would break the next `--locked` build. Nothing beyond that is written. `check` is pure: it reports drift and names the fix, never applies it.
+**Every command writes only the files it owns.** Oakum does not install git hooks, touch git config, edit `AGENTS.md`, write CI workflows, or create commits you did not ask for. `version` owns the manifests it bumps, the lockfile entries those bumps invalidate, declared `extra-files`, and — when the Cargo member named `oakum` is bumped — `tool-version` in `.changeset/_config.toml`. A Cargo version bump invalidates `Cargo.lock`, so leaving it stale would break the next `--locked` build. Nothing beyond that is written. `check` is pure: it reports drift and names the fix, never applies it.
 
 **Failure is loud, and "we didn't look" is never reported as "it's fine."** Every verification has three outcomes, not two. A version that could not be confirmed says so.
 

package/npm-shrinkwrap.json

@@ -19,7 +19,7 @@
       "hasInstallScript": true,
       "license": "MIT",
       "name": "@oakoss/oakum",
-      "version": "0.1.0"
+      "version": "0.1.1"
     },
     "node_modules/detect-libc": {
       "engines": {
@@ -48,5 +48,5 @@
     }
   },
   "requires": true,
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "artifactDownloadUrls": [
-    "https://github.com/oakoss/oakum/releases/download/v0.1.0"
+    "https://github.com/oakoss/oakum/releases/download/v0.1.1"
   ],
   "author": "Jace Babin",
   "bin": {
@@ -105,7 +105,7 @@
       "zipExt": ".tar.xz"
     }
   },
-  "version": "0.1.0",
+  "version": "0.1.1",
   "volta": {
     "node": "18.14.1",
     "npm": "9.5.0"