dotsec

    Release Workflow

    Versioning is fully automated using conventional commits and release-plz.

    Channels

    ChannelTriggernpm tagcrates.ioVersion format
    betaPush to mainbetaNo{version}-beta.{sha}
    prPR commitpr-{N}No{version}-pr-{N}.{sha}
    stableRelease PR mergelatestYes{version}

    Version is read from Cargo.toml (managed by release-plz via conventional commits).

    How it works

    1. Conventional commits land on main (feat:, fix:, feat!:)
    2. release-plz opens a "chore: release" PR with bumped versions
    3. You merge the PR
    4. release-plz publishes to crates.io and creates a GitHub release
    5. The GitHub release automatically triggers the npm stable publish (latest tag)

    Commit message → version bump

    CommitBump
    fix: handle empty valuespatch (5.0.0 → 5.0.1)
    feat: add push commandminor (5.0.0 → 5.1.0)
    feat!: redesign directive syntaxmajor (5.0.0 → 6.0.0)

    CI Workflows

    WorkflowFileDescription
    Publish CLI to NPMpublish-npm.ymlBuilds CLI binary for 6 platforms, publishes dotsec
    Publish Core npm packagepublish-napi.ymlBuilds NAPI bindings for 6 platforms, publishes @dotsec/core
    Deploy docsdeploy-docs.ymlBuilds and deploys documentation to GitHub Pages (versioned: stable, beta, PR previews)
    Release-plzrelease-plz.ymlAnalyzes conventional commits, creates release PRs, publishes to crates.io

    Why no crates.io for PRs?

    crates.io versions are permanent — you can't delete them, only yank. Publishing a crate for every PR commit would pollute the version history. npm has dist-tags so pre-releases are only visible when explicitly requested.