@spaethtech/svelte-ui 0.21.1-dev.135.8f54ea8 → 0.21.1

package/MIGRATION.md

@@ -8,15 +8,16 @@ upgrade are documented here, each with a dated heading and a concrete before/aft
 
 ## The `*2` native-first variants (transitional)
 
-> ### ⚠️ EXPERIMENTAL — proof-of-concept, NOT ready for use
+> ### ⚠️ EXPERIMENTAL — unstable API, adopt with care
 >
-> The `*2` components (`Select2`, `Disclosure2`, `Accordion2`, `DatePicker2`) are a **proof-of-concept
-> under active evaluation in a single test bed (php-svelte) only**. They ship on the **`@dev`** channel
-> so that test bed can exercise them — **do not adopt them in any other project yet.** The API, the
-> behaviour, and even whether each one survives are still in flux (e.g. reset semantics are still being
-> settled). Treat them as unstable: no compatibility promise, and they may change or be removed without
-> a migration note while in this phase. When one is actually ready, this banner comes off and the swap
-> is announced here. Until then: **look, test in php-svelte, don't build on them.**
+> The `*2` components (`Select2`, `Disclosure2`, `Accordion2`, `DatePicker2`) are **transitional
+> native-first variants under active evaluation**. They're published (not `@dev`-only), but the API,
+> the behaviour, and even whether each one survives are still in flux (e.g. reset semantics are still
+> being settled). Treat them as unstable: **no compatibility promise**, and they may change or be
+> removed without a migration note while in this phase. Adopt one only if you can track breaking
+> changes and pin exact versions. When one is actually ready, this banner comes off and the swap is
+> announced here. The stable originals (`Select`, `Disclosure`, `Accordion`, `DatePicker`) carry no
+> such caveat.
 
 Several components are getting a **native-first, no-JS / SSR-correct** rebuild so SSR apps (e.g. a
 PHP-rendered front end) render and submit them with **no client JavaScript**. Rather than change the
@@ -25,13 +26,13 @@ existing components in place and risk the apps that already depend on them, each
 
 - **Nothing breaks on arrival.** The `2` components are purely additive new exports. Existing
   components are untouched; your current code keeps working.
-- **Try them on `@dev`.** Import the `2` variant (`import { Select2 } from '@spaethtech/svelte-ui'`
+- **Try them.** Import the `2` variant (`import { Select2 } from '@spaethtech/svelte-ui'`
   or the `@spaethtech/svelte-ui/select2` subpath) and A/B it against the original in the same app.
 - **The eventual swap is deliberate and versioned.** Once a `2` variant proves out, its
   implementation replaces the original's (`Select2` → `Select`), the `2` export is removed, and that
   single swap is documented here with its compatibility delta and a MINOR version bump. The only
-  thing that can break at that point is a **direct `Select2` import** — which should only ever exist
-  in the test bed, never in shipped app code.
+  thing that can break at that point is a **direct `Select2` import** — so if you adopt one, pin exact
+  versions and track this file.
 
 The `2` variants aim to be a **drop-in prop-superset** of the original: props the native element
 can't honour are still *accepted* (so swapping the component name type-checks) but ignored, and are

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@spaethtech/svelte-ui",
-  "version": "0.21.1-dev.135.8f54ea8",
+  "version": "0.21.1",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/spaethtech/svelte-ui.git"