Upgrade the generator in its own pull request, regenerate into a scratch folder, review the diff, re-merge any custom templates, scan the dependencies and keep the old version ready for rollback. Treat it like upgrading a compiler: small, deliberate and reversible.
Why upgrades deserve care
A generator release can change templates, defaults, generated dependency versions and naming. Your clients and everything that calls them sit downstream. Security fixes in templates also arrive this way, so staying behind has its own cost. The aim is controlled change, not avoidance.
The routine
- Read the release notes. Look for changes that affect your generator and library choice, plus anything about defaults or dependency bumps.
- Branch. Make a branch that changes only the version, in the one file where you pin it. See how to pin the version in CI.
- Regenerate into a scratch directory. Do not write into your working tree yet. Use the same spec and config as production.
- Diff against the committed output. Review in the order laid out in what to check in a regeneration diff: build files, client and auth code, removals, then models.
- Re-merge templates. If you override templates, extract the new built in versions and compare. The docs describe a command, available since version 5.0, to extract embedded templates for a generator. Re-apply your change deliberately. Remember that your override wins over the built in file, so a stale one hides upstream fixes.
- Re-check ignored files. Files in the ignore list are not touched by regeneration, so port needed changes by hand. See the ignore file post.
- Scan. Run dependency scanning and your tests against the new output. Compare the dependency list before and after.
- Roll out in stages. Update internal consumers first, then external ones, with a version bump of the client that signals the change.
- Keep rollback simple. The old version is one line in the pin file, and the old output is in git history.
What to watch for
| Signal in the diff | Meaning |
|---|---|
| New or bumped libraries in build files | Review each, run the scanner |
| Different default for HTTP client behaviour | Test timeouts, redirects and TLS |
| Renamed methods or packages | Breaking change for callers, plan a major version |
| Files removed from the manifest | Confirm no one depended on them |
| Generator marked deprecated or experimental in the docs | Plan a move before it is removed |
The usage page shows that the list command can include stable, beta, experimental and deprecated generators, so you can check the status of the one you use.
How often
Set a cadence, such as every quarter, plus out of band when an advisory affects the generator or a library it emits. A regular rhythm keeps each jump small.
Where Safeguard fits
Safeguard's dependency scanning and policy gates apply to the upgrade pull request like any other, and its autonomous remediation can open fix PRs for vulnerable dependencies, off by default with every category on Manual.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the gate reports on a change before merge.
Quick check
Is it safe to stay on an old generator version?
It is stable, but you miss template and dependency fixes. Schedule regular, small upgrades.
Should the spec change in the same pull request?
No. Separate them so every diff line has one explanation.
Sources
Last reviewed: 19 October 2026.
