Supported Go versions

LiteORM targets the two most recent Go releases. The exact lower bound is pinned in the module’s go.mod — check there for the authoritative minimum rather than any number written here. Tracking a narrow, current window is a deliberate choice: it keeps the codebase free to use modern language and standard-library features directly, with no compatibility shims and no reflection fallbacks for things the type system now expresses.

The API leans on recent Go, and that is much of why it feels current instead of retrofitted:

• Generics. Both front-ends are generic over your model type — query.Select[T], orm.NewRepo[T] — and typed columns (query.Column[V]) thread the column’s value type through the compiler, so a predicate on an int column won’t accept a string. Without generics this surface would collapse back to any and runtime checks.
• iter.Seq2. Range-over-function iterators back the streaming result sets, so you can for row, err := range q.Iter(ctx) and process a large table without materializing it. This is a language feature, not a library trick — it needs a Go new enough to have it.
• log/slog. Structured logging integrates with the standard log/slog package rather than a bespoke logger, so LiteORM’s statement log flows into whatever slog handler your app already configures. See logging.

Alongside these headline features, the code uses smaller modern idioms freely — slices/maps helpers, strings.SplitSeq, reflect.TypeFor, cmp — wherever they are clearer than the older spelling. Each one raises the floor on the minimum Go, and the two-release policy is what makes that safe.

Print your toolchain, then compare it to the pin in go.mod:

go version
go mod edit -json | grep '"Go"'   # the module's declared minimum

If your go version is at or above the module’s declared go line, you’re inside the supported window. Because the window follows the two most recent releases, staying on a current toolchain keeps you supported without any per-release action on your part.

Upgrade your toolchain alongside each Go release and you never leave the range. When you do upgrade, bump the directive in your own go.mod too if you want your project to require the same floor:

go get go@latest        # or a specific line, e.g. go@1.x
go mod tidy

If you must stay on an older Go, pin a LiteORM release that still supported it — but the current line assumes a current toolchain, and new features land against the supported window.

• The go directive is a minimum, not a ceiling. A newer toolchain builds an older-declared module fine; LiteORM’s go.mod line is the lowest version the source is known to compile and pass tests on.
• toolchain auto-download. If your installed Go is older than a module’s go line, modern Go can fetch and use the required toolchain automatically (unless you set GOTOOLCHAIN=local). That means a slightly stale local install still builds LiteORM, though upgrading is simpler.
• Backends inherit the same policy. Each backend module (liteorm.org/dialect/*) tracks the same window, so a project mixing the core and a dialect has one consistent Go floor.

• Backends reference — the backends and their drivers.
• Releases & changelog — the release cadence and semver policy.
• Full API: liteorm.org.