chore(sdkx,voice): bump sdk dependency to v0.2.2#44
Merged
Conversation
sdkx/v0.2.1 and (will-be) voice/v0.2.x's source already targets the post-PR#42 sdk API surface (knowledge/retrieval refactor). Their go.mod still pinned the floor at sdk v0.2.0, which is fine under MVS when downstream apps require >= v0.2.2 themselves, but can break apps that only require sdkx/voice and let MVS pick sdk v0.2.0 (those apps would compile sdkx/voice against a sdk that predates the API additions used by the refactor). Lift the floor to sdk v0.2.2 so MVS always picks a sdk that is known to satisfy sdkx/voice's actual API usage. Build verified with GOWORK=off + GOPROXY against the real sdk@v0.2.2 module zip; race-tested with the workspace. Made-with: Cursor
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
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.
Summary
Lift
sdkx/go.modandvoice/go.mod'srequire github.com/GizClaw/flowcraft/sdkfloor fromv0.2.0tov0.2.2.Why
sdk/v0.2.1(PR#42, knowledge architecture refactor) andsdk/v0.2.2(PR#43, history compactor + knowledge reloader race fixes) added new API surface thatsdkx's andvoice's source already uses onmain. Theirgo.modstill pinned the floor atv0.2.0. This is silently OK in our monorepo becausego.workredirects to local code, and OK for downstream apps that themselves requiresdk >= v0.2.2, but it is not OK for an app that only requiressdkx/voiceand lets MVS picksdk@v0.2.0— that app would compilesdkx/voiceagainst asdkpredating the refactor and break.Lifting the floor to
v0.2.2makes Minimum Version Selection always pick asdkthat is known to satisfysdkx/voice's actual API usage.Tag implications
After merge,
auto-tagwill:sdk(nosdk/changes)sdkx(nowsdkx/v0.2.0→sdkx/v0.2.2, since the next free patch slot isv0.2.2;v0.2.1was deleted earlier as it pointed to the same code state as the now-merged catch-up tag would have)voice(voice/v0.2.0→voice/v0.2.1)This is the desired outcome —
sdkx/voiceconsumers get pointers to versions whosego.modcorrectly declares the sdk API they need.Test plan
GOWORK=off go build ./...insdkx/andvoice/against realsdk@v0.2.2module zipgo test -race ./...insdkx/andvoice/(workspace mode, fast feedback)Made with Cursor