Skip to content

release: publish npm alpha and verify clean-HOME install/uninstall #7

Description

@Altairpaca

Goal

Turn the current source-preview distribution into a verifiable public alpha that a user can install without knowing the repository layout.

Acceptance criteria

  • publish the alpha package set required by the public entry point (dshelm, @dshelm/dsh, and any internal packages that must be externally resolvable);
  • npx dshelm init --yes succeeds from a clean HOME with a supported DSH installation;
  • dshelm doctor reports the installed profile/bundle and gives an actionable next command;
  • uninstall removes DSHelm-owned discovery/profile state while preserving unrelated profiles and product-owned credentials;
  • record the exact package versions and DSH version used for verification;
  • create a GitHub prerelease with install, upgrade, limitations, and uninstall notes.

Evidence to attach

  • clean-HOME command transcript with secrets/user paths redacted;
  • installed profile/bundle paths;
  • doctor output before and after install;
  • uninstall proof showing unrelated state remains intact.

This is the P0 distribution gate from docs/community-roadmap.zh-CN.md; passing unit tests alone is not sufficient evidence for this issue.

Activity

  1. self-assigned this
    on Sep 3, 2026
  2. Altairpaca commented on Sep 3, 2026

    @Altairpaca
    OwnerAuthor

    Pre-release packaging audit (2026-09): the clean pack-install CI already exercises all six publishable artifacts (dshelm, @dshelm/core, @dshelm/dsh, @dshelm/auth, @dshelm/model-knowledge, @dshelm/compat-omo), but the package manifests are not yet consistently ready for a public npm surface.

    Before publishing the alpha, add a small release-hygiene pass:

    1. normalize package metadata (description, license, repository, homepage, bugs, engines, publishConfig.access=public) across every publishable package;
    2. ensure each npm package has a useful package-level README instead of an empty/minimal npm landing page;
    3. add a repository CHANGELOG.md and a maintainer release checklist documenting version/tag/prerelease order and the exact clean-HOME evidence required here;
    4. keep publish automation separate until the manual alpha path is proven once end-to-end.

    This deliberately defers Changesets/automatic publishing until after the first real registry release, so release tooling does not hide package-boundary problems.

  3. Altairpaca commented on Sep 3, 2026

    @Altairpaca
    OwnerAuthor

    Release-maintenance audit (2026-09-03): two version-coherence risks were found before the first public npm alpha.

    1. Fixed in PR fix: keep init bundle version aligned with installed CLI #18 / main: dshelm init had hard-coded @dshelm/dsh@0.3.0-alpha.0; it now derives the adapter bundle version from the installed CLI package version.
    2. Still a release gate: several published manifests declare verified DSH prerelease dependencies as ^0.1.0-rc.7, while compatibility.json and the current lockfile only verify 0.1.0-rc.7. A registry consumer is not protected by the repository lockfile and may resolve a later, unverified prerelease-compatible version. Before publishing release: publish npm alpha and verify clean-HOME install/uninstall #7, regenerate the lockfile together with exact DSH prerelease pins (or deliberately broaden compatibility only after evidence). Do not make a manifest-only change, because pnpm install --frozen-lockfile must continue to prove manifest/lockfile coherence.

    PR #17 also removes release-version literals from pack/install CI and makes the QA journey read the DSH package baseline from compatibility.json.tested.dshPackages.

  4. Altairpaca commented on Sep 3, 2026

    @Altairpaca
    OwnerAuthor

    2026-09-03 DSH 0.1.2 source-target update

    The latest upstream source release is now dsh-v0.1.2-rc.1. PR #21 prepares forward-compatible source bridges, but does not promote the verified install baseline.

    New release blocker discovered during the full package audit:

    • the 0.1.2 source tree no longer contains the old packages/client/runtime / @deepseek-ai/dsh-client-runtime package currently used by @dshelm/dsh;
    • @deepseek-ai/dsh-client-modules@0.1.2-rc.1 now owns dsh.client scanning, boot graph composition, /plugins bundle delivery and lazy module materialization;
    • DSHelm browser source in feat: bridge DSH 0.1.2 APIs and redesign the project landing page #21 is decoupled from the removed runtime type package, but packages/dsh/package.json intentionally remains on the verified legacy dependency/inject graph until the candidate manifests and pnpm-lock.yaml can move together.

    Exact promotion work is tracked in #20. The first npm alpha should not publish until #20 has resolved the 0.1.2 client graph (or selected another explicitly verified DSH baseline), regenerated the lockfile, and passed packed install + isolated profile boot + real Web client materialization.

    This adds to the previously recorded prerelease-range blocker: do not publish a mixed or caret-resolved DSH prerelease graph.

  5. Altairpaca commented on Sep 5, 2026

    @Altairpaca
    OwnerAuthor

    Update after PR #28 merge:

    Repository-side npm alpha bootstrap preparation is complete on main (680db824a0720c489641535718673ef59f514f4b). Verified:

    • guarded npm release workflow merged;
    • six-package release order validated;
    • deterministic package closure passed;
    • npm 11.19.1 npm publish --dry-run --access public --tag alpha succeeded for all 0.3.0-alpha.0 packages;
    • release evidence artifact: 9938939100 (sha256 376d1c1e3a9b4881ed0108ad199bfe5c36ad9de6027e87272f3c24666ea238bf).

    Remaining blocker is maintainer-side first publication bootstrap only: npm ownership/scope access, 2FA-enabled credential path, then immediate migration to Trusted Publishing/OIDC. After the first real publish, run public-registry clean-HOME smoke before closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions