2026 Q2

Q2 2026 — go-openapi Organization Summary

Period: April 1, 2026 — May 29, 2026 Overall effort: 352 commits across 18 repositories (16 go-openapi libraries + the go-swagger toolkit and its examples)

This period was concentrated, feature-driven work rather than the broad organization-wide infrastructure sweeps of the two previous quarters. It had two clear centers of gravity — runtime and codescan — supported by continued factoring of code out of go-swagger, steady maintenance of the test framework and CI platform, and consolidation of organization-wide documentation. Downstream, the go-swagger toolkit broke a long release standstill and shipped v0.34.0; it is covered in §3.

1. runtime: Refactoring & Package-Layout Reorganization

The largest single effort this quarter, runtime progressed from v0.29.3 through v0.32.2 (seven releases). This was a careful refactoring and reorganization of the package layout, not a rewrite: the public v0.29 API surface was deliberately preserved, so the changes are non-breaking for downstream consumers.

A new standalone middleware module. The server middleware was extracted into its own module, github.com/go-openapi/runtime/server-middleware, with no go-openapi runtime dependencies (its only requirement is the test framework). It bundles the documentation UI (docui), typed media-type handling (mediatype), and content negotiation (negotiate) as middleware that is reusable on its own — in any net/http server, including outside the go-openapi ecosystem.

Context-first client request building.

• New SubmitContext entry point; BuildHTTP now threads a context.Context end-to-end
• request moved to its own internal package; context cancellation honored in the multipart upload goroutine; streaming bodies closed on buildHTTP error paths
• OpenTelemetry transport (client-middleware/opentracing) pivoted to SubmitContext; ContextualTransport promoted to the runtime package

Content negotiation and media types.

• New typed media-type package with symmetric Accept negotiation; negotiate extracted into the server-middleware module
• findByCanonical extracted from Lookup; content-type matching now respects MIME parameters; validateContentType distinguishes 400 from 415

A curl-style connection diagnostic. A new Runtime.Trace adds a curl-style, connection-level diagnostic to the client — surfacing TLS handshake details (with correct PEM labels and Ed25519 key support) to make connection troubleshooting straightforward.

Other additions. A BindForm helper for multipart / urlencoded body binding, and a build-tag-gated SetSkipAuth dev-mode auth bypass with a dedicated unsafe-skipauth tagged CI build.

Security hardening

A focused security pass accompanied the refactor:

• Filename length capped on untyped formData uploads; CR/LF stripped from multipart filename and field names
• Fuzz targets added for the BindForm parser, filename capping, and the header-parsing surface
• Content negotiation rejects q-values greater than 1; CA cert pool cloned rather than shared by pointer; constant-time-comparison contract for auth callbacks documented

Issue cleanup and documentation. This work closed essentially every open issue on the repository — only one remains (#53, a long-standing request that hits an architectural wall and is deferred to a future v2). runtime now also publishes its own documentation site at https://go-openapi.github.io/runtime/, with extensive, detailed code examples.

2. codescan & the diff Package: Factoring Code Out of go-swagger

A long-running goal of the organization is to factor reusable components out of the monolithic, hard-to-maintain go-swagger project into independently versioned go-openapi modules. Two such moves landed this quarter; both began at the Q1 report’s March 17 cutoff, so neither appeared there.

codescan

codescan — the engine that generates an OpenAPI (Swagger) specification by scanning Go source and parsing swagger annotations — was historically the least maintainable and least stable part of go-swagger. It was spun off into its own repository, imported with full history (commits back to 2015), and has since become a major focus.

Merged this quarter:

• A new package layout to reason more clearly about code scanning versus annotation parsing (#15), followed by dead-code removal (#17)
• A batch of scanner/parser/schema correctness fixes: swagger:type array fallthrough to the underlying type, allOf resolution when a member is a TextMarshaler, aliased TextMarshaler capture, multiple enum values assigned in one statement, stripping the in: parameter/header location and duplicate words from generated descriptions, ignoring annotations buried in prose, and preventing structs marked as strfmt from resurfacing
• Configuration via options instead of environment variables (#5), relinting, and a Go toolchain bump

In progress (only partially merged for Q2 — the team is treading cautiously here): a substantial rewrite that retires the 60–70 complex regular expressions at the heart of the tool, replacing them with a structured grammar-based parser (with dedicated sub-parsers and a pluggable diagnostic sink). Parallel efforts aim to improve diagnostics and performance — codescan is memory-bound on large code bases. Only a fraction of this work could be safely merged this quarter; the larger part is still being staged. codescan cut its first go-openapi GitHub release, v0.34.0.

analysis: the diff package

The swagger spec diff functionality — comparing two specifications and reporting compatible versus breaking changes — was imported from go-swagger into the analysis repository as a new diff package, again with full history, and shipped in analysis v0.25.0.

3. go-swagger: Release Standstill Broken, Toolkit Slimmed

The go-swagger toolkit — the downstream code generator that consumes the go-openapi libraries — is its own articulated effort alongside the libraries, and its Q2 progress is part of the same story. After a long release standstill (no feature release since v0.33.1 in October 2025), go-swagger rebased onto the modernized go-openapi libraries (notably adapted to runtime v0.32.x) and resumed shipping: 29 issues were closed this quarter and v0.34.0 was released on May 29, 2026 (35 commits this quarter, 67 year-to-date).

Release infrastructure modernized. Releases are now produced with goreleaser (ci: release workflow with goreleaser), with automated release notes and Discord announcements — a substantial rework of the release pipeline that took several iterations to stabilize.

Completing the monolith split. Continuing the factoring effort described above, the bundled code examples were spun off into their own repository, go-swagger/examples — imported with full history (340 commits back to 2014) across 22 example projects with generated clients/servers plus custom code. A CI workflow now regenerates the examples and opens an automatic PR against that repository (25 commits this quarter), keeping them in sync with the generator. Together with codescan and analysis/diff, this leaves the core go-swagger repository markedly slimmer.

Code generation modernized. The generator was updated to match the refactored runtime: generated clients now use the idiomatic SubmitContext and expose a context-aware operation interface, internal Params fields (timeout, context) were moved into their own struct, and client-side custom producers/consumers can be configured. The generator’s template repository, funcmaps, and language config were split apart for maintainability, alongside validation-template fixes (aliased primitive $ref required checks, the ReadOnly template, enum operator characters) and codescan annotation-scanner fixes (gRPC/protoc false matches, nil-check panics).

4. jsonpointer & swag: Reflection-based JSON Naming

jsonpointer (v0.23.1) reached feature completeness: with support for the RFC 6901 "-" array suffix and a pluggable, non-default JSON name provider now in place, the package fully covers the specification. The JSON name provider lets jsonpointer reconstruct JSON field names from Go structs via reflection. swag (v0.26.0) added a complementary name provider that better respects Go’s conventions for JSON naming.

5. strfmt: Duration Performance

strfmt (v0.26.2) gained a faster and stricter ParseDuration, alongside docs alignment with the org-wide documentation and continued MongoDB integration tests under internal/testintegration.

6. Documentation & Doc Sites

• runtime carried out a large documentation effort and now publishes its own doc site at https://go-openapi.github.io/runtime/, with extensive, detailed code examples (see §1)
• doc-site (this repository) hosts documentation common to the whole organization — code style, contributing guidelines, and generic maintainer documentation — so individual repos no longer repeat it. It now also publishes news and announcements (cross-posted to the project’s Discord), including these quarterly reports
• Across several repositories, per-repo docs were trimmed to point at the organization-wide site, and godoc coverage was completed (notably errors and jsonpointer)

7. testify/v2: Steady Cadence

testify/v2 did not change direction this quarter; it kept pace at roughly one minor release a month (v2.5.0, v2.5.1), following its published roadmap. New assertions continued to arrive incrementally (generic slice/map equality, channel Blocked/NotBlocked, opt-in synctest support in async assertions, JSON/YAML redactors, macOS file-descriptor leak detection), and the migration tool was kept in step. A GitHub discussion is ongoing about whether to restore test-suite support, which was deliberately dropped when the fork was first created.

8. CI/CD & Dependency Management

The shared CI platform — ci-workflows (v0.2.17) and gh-actions (v1.4.14) — is checked for updates daily. A key refinement this quarter: CI-related dependency updates are now throttled before propagating to downstream repositories, so frequently-updated actions (such as taiki-e/install-action) no longer flood every go-openapi repo with churn. ci-workflows also gained a workflow to monitor stalled bot PRs and a fuzz fix for running multiple fuzz tests per package. Dependency maintenance otherwise proceeded across all repositories (testify/v2 bumps, go-openapi dependency cascades, and golang.org/x security updates).

Impact Assessment

Repository Highlights

Summary

Q2 2026 was concentrated, feature-driven work rather than the broad infrastructure sweeps of the two previous quarters, with two clear centers of gravity: runtime and codescan.

runtime was refactored and reorganized rather than rewritten: a context-first client, a new standalone server-middleware module reusable in any net/http server, a curl-style connection diagnostic, and a focused security pass — all while preserving the v0.29 public API. The effort closed essentially every open issue on the repository (one long-standing item remains, deferred to a future v2) and shipped alongside a new runtime documentation site.

codescan, freshly spun off from go-swagger, was refactored around a clearer package layout and is undergoing a cautious, still-in-progress rewrite to retire the 60–70 regular expressions that drove its annotation parsing, with parallel work on diagnostics and performance. Only a fraction of that effort could be merged this quarter; the larger part is still being staged. The diff package was likewise imported from go-swagger into analysis. The feature libraries advanced too: jsonpointer reached feature completeness, swag refined Go-aware JSON naming, and strfmt tightened duration parsing.

Downstream, the go-swagger toolkit returned to active releases after a long standstill: once rebased onto the modernized go-openapi libraries it closed some 29 issues, moved its release process to goreleaser, completed the monolith split by spinning off its bundled examples into a dedicated repository, and shipped v0.34.0.

The organization’s infrastructure stayed healthy in the background: testify/v2 kept a steady, roadmap-driven cadence; ci-workflows and gh-actions continued to centralize CI and now throttle updates to downstream repos; and the new doc-site consolidated organization-wide documentation and announcements. No breaking API changes were introduced.

Most go-openapi repositories have now reached a satisfactory level of maturity — in code quality, documentation, and a low count of pending issues. The expectation is that most of them (codescan being the likely exception — it needs another push) will be released as v1.0 at some point next quarter, clearing the way to begin work on a v2.

Thanks to Our Contributors

A warm thank-you to the community members who contributed to go-openapi and go-swagger this quarter. Whatever its size, every contribution helps keep the project healthy — we’re grateful for your time and care:

• @KT-Doan — codescan
• @alexandear — jsonpointer
• @KuaaMU — runtime
• @boekkooi-impossiblecloud — testify
• @dashitongzhi — go-swagger
• @Abzaek — go-swagger

Thank you all. 🙏