Skip to content

v2.1.0

Latest
Latest

Choose a tag to compare

View all tags
@flyingrobots flyingrobots released this 01 Jun 10:40
v2.1.0
This tag was signed with the committer’s verified signature.
flyingrobots James Ross
GPG key ID: 39560E0406CA9135
Verified
Learn about vigilant mode.
5061aa1
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

title: "v2.1.0"

v2.1.0

Summary

METHOD v2.1.0 moves live work tracking to GitHub Issues while keeping
Method's design docs, witnesses, playbacks, retros, and release packets
as durable repository evidence.

What Changed

  • GitHub Issues are the live tracker: lanes, work-in-progress state,
    legends, priorities, and work types are represented as labels.
  • Repository files are the evidence ledger: design docs, witnesses,
    retros, release notes, and migration archives remain in git.
  • Issue templates: work-item, bug, and spike templates now capture
    sponsored perspectives, witness plans, and Method artifact links.
  • PR template: pull requests link implementation work back to
    GitHub Issues and Method evidence.
  • Backlog migration tooling: npm run migrate can convert legacy
    filesystem backlog cards into GitHub Issues with source provenance.
  • Method pilot migration: the Method repo's live backlog cards were
    migrated to GitHub Issues and archived under the graveyard.
  • Migration hardening: duplicate source markers, unknown lanes,
    malformed issue-create output, and GitHub issue-loading failures now
    fail closed.
  • Dependency cleanup: GitHub Dependabot alerts against the previous
    default branch state are fixed.

Why It Matters

This release makes Method easier for OSS contributors to approach:
GitHub Issues are the familiar work surface, while Method keeps its
stronger evidence model in the repository. Contributors can find and
claim work without learning a filesystem backlog first, and agents get
stable labels, issue links, branch slugs, and artifact prompts.

Breaking Changes

No runtime or CLI breaking changes are intended in this release.

Migration

No package-consumer migration is required.

Repository operators adopting the new workflow should:

  1. Treat GitHub Issues as the live tracker.
  2. Use labels for lanes, legends, priority, type, and active work.
  3. Keep design docs, witnesses, retros, and release packets in git.
  4. Use npm run migrate -- --repo OWNER/REPO for legacy backlog cards
    only after reviewing existing GitHub Issues and migration output.

Links

Assets 2
Loading