tier-check: support monorepos with multiple SDK packages
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- typescript
Research direction
Start by reading the release detection logic in src/tier-check/checks/release.ts and trace how tier-check invokes it and fetches releases. Compare the stable-release and spec-tracking paths, then define how package or tag-prefix selection should apply; done means both paths consistently select the intended package release without mistaking a canary for stable.
Written by the indexing model from the issue text.
Description
We maintain a monorepo (mcp-use/mcp-use) that contains both a Python SDK and a TypeScript SDK. The tier-check command has a couple of issues with this setup:
-
Stable Release detection picks up the wrong release. Our TypeScript canary releases (e.g.
mcp-use@1.18.0-canary.3) get detected as the "latest version" instead of the stable Python release (v1.5.2). The check then fails because it sees a pre-release identifier. -
Spec tracking gap calculation may be picking up the wrong release tag for the same reason, it doesn't know which package's releases to look at.
The release detection logic fetches the latest 20 releases and picks the first one, which doesn't account for repos publishing releases for multiple packages with different tag patterns.
Would it be possible to support a --package or --tag-prefix flag to filter releases by package name (e.g. --tag-prefix python-v or --package mcp-use)?
Also, is tier-check intended as a self-assessment helper for SDK maintainers, or will it be used systematically to determine the official tier of each SDK as described in the SDK Tiering System? Asking because the answer affects how much we need to adapt our release tagging vs. how much the tool should adapt to different repo structures.
- Dominant language
- TypeScript
- Stars
- 127
- Forks
- 101
- Avg merge
- 4d 7h
- Merged PRs (30d)
- 6
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from modelcontextprotocol/conformance
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
modelcontextprotocol/conformance#315 · 1 comment ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
modelcontextprotocol/conformance#312 · 1 comment ·
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
Difficulty 4/5 3-5 days Newbie friendliness 40/100
-
Difficulty 3/5 1-2 days Newbie friendliness 65/100
All issues in modelcontextprotocol/conformance
Similar issues
-
blocklist removal
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
MetaMask/eth-phishing-detect#296544 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
pastelsky/bundlephobia#1122 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
category/development priority/P2 scope/file-operations scope/testing type/enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Enatega Customer and Rider app: Add-ons price is not visible to customer after order is placed. Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100