chore(release): cut miner v3.1.1#7086
Closed
JSONbored wants to merge 1 commit into
Closed
Conversation
Contributor
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
loopover-orb
Bot
added
the
gittensor:bug
|
Note LoopOver command help
Command: Command resultCommands
Findings
Evidence
Next actions
Source and freshness
Additional safe details
Feedback
💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers. |
Owner
Author
5 tasks
philluiz2323
pushed a commit
to philluiz2323/gittensory
that referenced
this pull request
Jul 17, 2026
…rsions @loopover/mcp and @loopover/miner are both live on npm at 3.1.1 (published via an out-of-band manual release cut, JSONbored#7064), but .release-please-manifest.json was never updated to match -- it still recorded 3.1.0 as the last-released version for both. release-please used that stale baseline to recompute and re-propose "cut v3.1.1" as a brand-new release (JSONbored#7086, JSONbored#7087), which would fail on publish: npm rejects republishing an already-published version.
4 tasks
luciferlive112116
pushed a commit
to luciferlive112116/gittensory
that referenced
this pull request
Jul 17, 2026
The actual root cause of the mcp/miner v3.1.x release churn: engine's release and its dependents' (mcp, miner both carry a real runtime `dependencies` entry on it) release each landed as SEPARATE PRs/commits. release-please's node-workspace plugin still bumped a dependent's `@loopover/engine` version range the moment engine's version changed, but on the dependent's OWN branch -- so the dependent's package.json ended up requiring an engine version that existed nowhere (not locally, since engine's bump lived on a different unmerged branch; not on npm, since it hadn't published yet). `npm ci` failed with ETARGET until a human manually walked engine through to publish first, then updated the dependent's branch -- confirmed live across JSONbored#7086/JSONbored#7087/JSONbored#7107/JSONbored#7108. merge: true is the plugin's own purpose-built mechanism for exactly this: it combines a package with the dependents its OWN dependency-bump logic pulled in as candidates into ONE PR/commit, so engine's new version and its dependents' bumped ranges land together atomically. npm workspaces then resolves the dependency from the LOCAL checkout, which always satisfies the range regardless of npm registry publish timing or ordering -- eliminating the failure mode structurally rather than papering over it with an after-the-fact branch-update step. ui-kit has no dependency edge to any other package here, so it's never pulled into the merge and keeps its fully independent release cadence.
galuis116
pushed a commit
to galuis116/gittensory
that referenced
this pull request
Jul 18, 2026
…nd-editing it JSONbored#7100 fixed the immediate mismatch by hand-typing corrected version numbers into .release-please-manifest.json -- exactly the failure mode that caused the drift in the first place (a human-authored value instead of one derived from source of truth). This replaces that with a real mechanism: - scripts/sync-release-manifest.mjs treats each package's own package.json "version" as authoritative and syncs the manifest to match -- `npm run release-manifest:sync` is now the only supported way to fix drift, never a manual edit. - `npm run release-manifest:sync:check` (wired into both test:ci and .github/workflows/ci.yml, gated on backend/mcp/engine/miner/ui) fails CI the moment the manifest and a package.json disagree, instead of surfacing days later as release-please re-proposing an already-published version (JSONbored#7086/JSONbored#7087). - .release-please-manifest.json and release-please-config.json are now part of the `backend` path filter so editing either alone still triggers the check. Also corrects reference.md's CI check table, which still claimed manifest:drift-check/engine-parity:drift-check weren't wired into ci.yml -- stale since JSONbored#7067 actually added them.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 I have created a release beep boop
3.1.1 (2026-07-17)
Fixes
Dependencies
This PR was generated with Release Please. See documentation.