release: pin sub-modules to v0.4.0 - #79
Merged
Merged
Conversation
The eight satellites required v0.3.0, so a consumer building one without this repo's go.work compiled it against the published 0.3 core — which predates the uniform rule config, so a .sqlguard.yml naming slow-query or a plan rule would still be rejected there. Verified with GOWORK=off, the only run that resolves the satellites against the real published tag rather than this tree: all 14 packages pass. That also confirms none of them called middleware.NewQueryTracker, whose signature this release changes.
Contributor
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Repository: KARTIKrocks/sqlguard/.coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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.
Summary
Step 2 of the 0.4.0 release, following #78 and the
v0.4.0root tag. Points the eight satellite modules at the core version just published.The satellites required
v0.3.0, so anyone buildinggormguard,pgxguardor a parser without this repo'sgo.workcompiled it against the 0.3 core — which predates the uniform rule config, so a.sqlguard.ymlnamingslow-queryor a plan rule would still be rejected there. The workspace hides that completely:make testpasses either way.16 files: 8 ×
go.modplus thego.sumupdates frommake tidy.Type of change
Checklist
make cipasses (fmt-check, vet, lint, vuln, test-race, lint-docs) across all moduleswebsite/docs/with a version marker for anything newAGENTS.md/.sqlguard.example.ymlif a convention or config key changed## [Unreleased]inCHANGELOG.mdanalyzer/middleware/reporterResult)No tests, docs,
AGENTS.mdor changelog entry: this is dependency bookkeeping that ships no behaviour, and 0.4.0's entry is already onmainfrom #78.Verification
GOWORK=off make test— all 14 packages pass. The only run that proves anything here: with the workspace off, each satellite resolvesgithub.com/KARTIKrocks/sqlguardfrom the module proxy, so this confirms thev0.4.0tag is fetchable and that every integration and parser compiles and passes against the real published core rather than this working tree.That matters more this release than last, because 0.4.0 carries a breaking
middlewareAPI change —NewQueryTrackergained aseverityargument. A green run here is the evidence that no satellite was calling it.make test(withgo.work) also passes, andmake tidyleft no further changes.After this merges
Last step: tag each satellite at
<mod>/v0.4.0and push, perCONTRIBUTING.md. Those tags must point at this commit, since that is where eachgo.modrequires the matching core. Then publish the release notes, leading with the two migrations.