Skip to content

[Stage 0.3] Establish independent v1 and v2 CI, preview, and release workflows #313

Description

@draedful

Parent: #310

Goal

Give v1 and v2 independent, explicit delivery paths before the v2 branch is opened for migration work.

Scope

  • Run the agreed CI suite for pull requests and relevant pushes on both main and the future v2 branch.
  • Keep main and v2 Storybook or documentation previews on distinct destinations.
  • Replace the shared conditional release workflow with two explicit workflows:
    • release-v1.yml
    • release-v2.yml
  • Configure the v1 workflow before cutover:
    • stable branch: main
    • permitted versions: 1.x
    • npm dist-tag: latest
  • Prepare the same v1 workflow for the future maintenance line:
    • branch: release/v1
    • permitted versions: 1.x
    • npm dist-tag: v1
  • Configure the v2 workflow before cutover:
    • branch: v2
    • permitted versions: 2.x prereleases
    • npm dist-tag: next
  • Design the v2 workflow so that cutover changes only its branch and stable-channel configuration:
    • branch: main
    • permitted versions: stable 2.x
    • npm dist-tag: latest
  • Add branch, version, and dist-tag guards that fail before publication.
  • Provide dry-run or equivalent release-routing verification.
  • Keep publication behind an explicit release pull request or approval step.
  • Confirm that the release GitHub App can operate under the planned rulesets with only the minimum required bypass.

Acceptance criteria

  • CI is configured for both main and v2.
  • Main and v2 previews cannot overwrite one another.
  • Separate v1 and v2 release workflows exist.
  • Before cutover, a non-1.x release from main fails before publishing.
  • Before cutover, the v2 workflow targets v2, permits only 2.x prereleases, and cannot update latest.
  • The future release/v1 route is present before that branch is created.
  • The post-cutover main/latest configuration for the v2 workflow is documented and testable.
  • Release routing can be verified without an accidental publication.
  • Publication always requires a reviewed release pull request or equivalent approval.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions