Skip to content

chore: migrate to start-sdk 2.0#4

Open
helix-nine wants to merge 5 commits into
masterfrom
next
Open

chore: migrate to start-sdk 2.0#4
helix-nine wants to merge 5 commits into
masterfrom
next

Conversation

@helix-nine

Copy link
Copy Markdown
Contributor

start-sdk 2.0 migration

Migrates this package to @start9labs/start-sdk 2.0 (requires StartOS 0.4.0-beta.10).

Changes

  • SDK pin → 2.0.1, TypeScript → ^6, tsconfig.json extends the shipped tsconfig.base.json, Makefile includes the SDK's s9pk.mk (vendored copy removed), reusable CI workflows repointed to Start9Labs/start-technologies.
  • 2.0 API migrations as applicable: sdk.serviceInterface.*sdk.host.* resolved over the LXC bridge, lazy SubContainer, alerts manifest field removed, and other ### Changed / ### Removed items from the SDK 2.0 changelog.
  • Downstream revision bump with release notes; package docs brought onto the current packaging-guide convention.

Test plan

  • CI build is green (npm citsc → SDK lint → nccs9pk pack).
  • Install the built .s9pk on a StartOS 0.4.0-beta.10 server.
  • Start the service; confirm it reaches its health check and primary interface.
  • For dependents: confirm it connects to its dependency over the LXC bridge.

🤖 Generated with Claude Code

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F5qZh4QiVySBLkV5ya7XSr
Bumps @start9labs/start-sdk 2.0.1 -> 2.0.3 (dependency and lockfile only).

- 2.0.3 fixes a dependency-gated daemon wedging permanently after its
  dependency's readiness flaps: Daemon.term() unconditionally destroyed the
  daemon's SubContainer, so the next start() threw "already destroyed" and the
  daemon never recovered. Adds a non-destroying Daemon.stop() for
  dependency-driven pauses, and serializes pause/resume transitions.
- 2.0.2 runs s9pk.mk's check-deps before packing, not just before install.

No packaging API changed between 2.0.1 and 2.0.3, so no source changes were
needed. Verified with `npm run check` (tsc --noEmit).
Bumps @start9labs/start-sdk 2.0.3 -> 2.0.5 (dependency and lockfile only).

2.0.5 fixes ExVer range operations ignoring the downstream revision:
compareVersionRangePoints and adjacentVersionRangePoints compared the upstream
twice, so two points sharing an upstream but differing downstream (1.0.0:3 vs
1.0.0:15) collapsed into one. normalize() then dropped the lower of the two,
which made packed manifests advertise a canMigrateFrom/canMigrateTo range
narrower than the truth for any package whose `other` versions share current's
upstream. No upgrade path actually broke — StartOS resolves migrations through
the version graph rather than this field — but the manifests were wrong.

No packaging API changed, so no source changes were needed. Verified with
`npm run check` (tsc --noEmit).
Upstream version bump. Pins the image/build to 0.55.8 and moves the package
version 0.55.7:5 → 0.55.8:0. Release notes rewritten for the new version in all five
locales from the actual upstream release notes.

The upstream artifact was verified to exist before pinning (image manifest /
release asset resolved), not inferred from a release listing.

Verified with `npm run check` (tsc --noEmit).
Bumps @start9labs/start-sdk 2.0.5 -> 2.0.6 (dependency and lockfile only).

2.0.6 fixes s9pk.mk failing under `make` in a git repo with no index yet: it
listed $(GIT_DIR)/index as an unconditional prerequisite, but `git init` creates
no index until the first `git add`, so a freshly scaffolded package aborted with
"No rule to make target '.git/index'" before packing. GIT_DEPS now filters
through $(wildcard ...), so a missing HEAD or index drops out of the prerequisite
list instead of halting the build (s9pk pack already handles a commit-less repo).
Build plumbing only.

No packaging API changed, so no source changes were needed. Verified with
`npm run check` (tsc --noEmit).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant