@bitbaum/ai-kit 0.16.0 → 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +44 -0
- package/package.json +2 -2
package/README.md
CHANGED
|
@@ -361,6 +361,50 @@ locally.
|
|
|
361
361
|
anything to do with AI. An app that throttles its login form should not install a
|
|
362
362
|
model catalogue to do it.
|
|
363
363
|
|
|
364
|
+
## Versioning
|
|
365
|
+
|
|
366
|
+
**This package is 1.x, and that is a functional decision rather than a
|
|
367
|
+
milestone.**
|
|
368
|
+
|
|
369
|
+
While it was `0.x`, every consumer was frozen at whatever minor it first
|
|
370
|
+
installed, and nobody chose that. A caret range on a pre-1.0 version does not
|
|
371
|
+
cross a minor — `^0.13.0` resolves to *at least 0.13.0 and below 0.14.0* —
|
|
372
|
+
because semver treats a `0.x` minor as a breaking change. So eleven repos sat on
|
|
373
|
+
five different versions of this package, spanning `0.6.2` to `0.15.0`, while the
|
|
374
|
+
registry served `0.16.0` to none of them.
|
|
375
|
+
|
|
376
|
+
The automation was not broken and nobody was neglecting it. Dependabot ran weekly
|
|
377
|
+
in every one of those repos, correctly classified each `0.x` minor as a breaking
|
|
378
|
+
change, and correctly routed it to its own pull request for a human to review —
|
|
379
|
+
which is the right policy for a breaking change and the wrong outcome for a
|
|
380
|
+
package whose minors were additive in practice. The version numbering defeated
|
|
381
|
+
the process.
|
|
382
|
+
|
|
383
|
+
From here:
|
|
384
|
+
|
|
385
|
+
- **Minor releases are additive.** New exports, new providers, new options with
|
|
386
|
+
defaults. Safe to take automatically, and your caret range will.
|
|
387
|
+
- **Major releases remove or change something.** They get a migration note and
|
|
388
|
+
they are meant to be read before merging.
|
|
389
|
+
- **Patch releases fix behaviour** without changing the surface.
|
|
390
|
+
|
|
391
|
+
The upgrade *to* 1.0.0 is the one exception, and it is a real one: a repo coming
|
|
392
|
+
from `0.6.x` crosses ten minors of a package that was permitted to break at each
|
|
393
|
+
of them. Run your own suite. Afterwards, the point is that you will not have to
|
|
394
|
+
again.
|
|
395
|
+
|
|
396
|
+
### Keep the volatile things out of the version
|
|
397
|
+
|
|
398
|
+
Model ids rot on a timescale of weeks — vendors retire them with little notice,
|
|
399
|
+
and a free catalogue rotates faster than that. Anything on that clock does not
|
|
400
|
+
belong in a release, because shipping it means a version bump per rot and one
|
|
401
|
+
upgrade per consumer to deliver a fact that was true yesterday.
|
|
402
|
+
|
|
403
|
+
So this package ships the *logic* — how to discover a catalogue, how to walk a
|
|
404
|
+
chain, how to read a refusal — and keeps the perishable data in the environment
|
|
405
|
+
and in live catalogue fetches. That is what makes being a version behind
|
|
406
|
+
uninteresting, which is a better property than being always current.
|
|
407
|
+
|
|
364
408
|
## Development
|
|
365
409
|
|
|
366
410
|
```bash
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@bitbaum/ai-kit",
|
|
3
|
-
"version": "0.
|
|
4
|
-
"description": "One install for the AI layer of an app: which model to call, what to do when the vendor retires it, how to walk the fallback chain and know when none of it worked, how to read the three kinds of 429, a fair daily budget across users, headless AI form filling
|
|
3
|
+
"version": "1.0.0",
|
|
4
|
+
"description": "One install for the AI layer of an app: which model to call, what to do when the vendor retires it, how to walk the fallback chain and know when none of it worked, how to read the three kinds of 429, a fair daily budget across users, headless AI form filling \u2014 and now the model registry (one SSOT for every callable id, with the paid/free boundary as a field) and the grounding harness (facts, contract, deterministic fabrication check).",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"author": "Mao Nakamoto",
|
|
7
7
|
"homepage": "https://github.com/bitbaum/ai-kit#readme",
|