release-v441: bump spec and PyPI bases - #2994
Conversation
Unblock the release train: spec 441 for a new on-chain upgrade, and bittensor 11.0.2 / bittensor-core 0.1.2 bases so stable PyPI can publish after mainnet executes. Co-authored-by: Cursor <cursoragent@cursor.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🛡️ AI Review — Skeptic (security review)VERDICT: SAFE MEDIUM scrutiny: account is ~4 months old, mitigated by repository write access and extensive substantive contributions; final commit uses a second author account, and no Gittensor association was found. Branch: release-v441 → main. The newly inventoried proxy calls retain FindingsNo findings. ConclusionThe patch introduces no malicious behavior or security vulnerability. 🔍 AI Review — Auditor (domain review)VERDICT: 👎 UNKNOWN Gittensor association; established high-volume contributor with repository write access. Overlapping PRs are unrelated despite sharing commonly edited runtime files. The runtime and package version bumps are coherent, and the release workflow’s new idempotent Python-publication check appears intentional. However, the PR description’s “version pumps only” claim omits the workflow behavior change, newly permitted root-proxy calls, and test rewrite. Findings
Prior-comment reconciliation
ConclusionThe Python package manifests remain inconsistent with the committed lockfile. Regenerate and commit 📜 Previous run (superseded)
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| [project] | ||
| name = "bittensor" | ||
| version = "11.0.1.dev0" | ||
| version = "11.0.2.dev0" |
There was a problem hiding this comment.
[MEDIUM] Regenerate the Python lockfile after both version bumps
sdk/python/uv.lock still identifies the editable bittensor package as 11.0.1.dev0 and the local bittensor-core package as 0.1.1. CI runs uv sync --locked, which rejects a lockfile that is stale relative to these project files. Run uv lock from sdk/python/ and commit the resulting lockfile updates for both packages.
|
🔄 AI review updated — Skeptic: SAFE Auditor: 👎 |
Co-authored-by: Cursor <cursoragent@cursor.com>
| [project] | ||
| name = "bittensor" | ||
| version = "11.0.1.dev0" | ||
| version = "11.0.2.dev0" |
There was a problem hiding this comment.
[MEDIUM] Regenerate the Python lockfile after both version bumps
sdk/python/uv.lock still records the local bittensor package as 11.0.1.dev0 and bittensor-core as 0.1.1. Regenerate and commit the lockfile after these metadata changes so locked uv operations resolve the release versions consistently.
|
🔄 AI review updated — Skeptic: SAFE Auditor: 👎 |
| [project] | ||
| name = "bittensor" | ||
| version = "11.0.1.dev0" | ||
| version = "11.0.2.dev0" |
There was a problem hiding this comment.
[MEDIUM] Regenerate the Python lockfile after both version bumps
sdk/python/uv.lock still records the local bittensor package as 11.0.1.dev0 and bittensor-core as 0.1.1, while this PR changes them to 11.0.2.dev0 and 0.1.2. Regenerate and commit the lockfile so locked uv operations remain consistent with both manifests.
|
🔄 AI review updated — Skeptic: SAFE Auditor: 👎 |
2 participants
Summary
spec_version440 → 441 so the release train can propose a new upgradebittensor11.0.2.dev0,bittensor-core0.1.2 (11.0.1 / 0.1.1 already on PyPI)No release notes or feature changes — version pumps only so the train can cut a new stable after mainnet executes.
Test plan
11.0.2/0.1.2Made with Cursor