You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our CI matrix only varies the PostgreSQL version. It never validates that we
actually support the oldest version of a dependency we claim to require
(e.g. META.in.json's cat_tools: 0.3.0 floor) — we only ever build/test
against whatever's current. If the floor drifts out of sync with reality
(newer dependency features get used without bumping the declared floor), CI
won't catch it.
Proposed shape (from prior discussion, not a committed design)
A dependency-version axis, orthogonal to the PG-version matrix, testing each
declared dependency at three points:
floor — the oldest version declared in META.in.json's prereqs.
Blocking. Catches accidental use of dependency features newer than the
declared floor.
master (dependency's development tip) — non-blocking (allow-failure
or scheduled), early warning for upcoming breakage in the dependency.
To avoid matrix blow-up: run the full PG-version matrix only for the
"released" point; run "floor" and "master" at just the min and max supported
PG versions.
This needs a reusable installer, something like install-dep <name> <pgxn|git> <version-or-ref> [pg_config], generalized out
of the one-off cat_tools git-pin Makefile target added in #10.
Current blocker
For cat_tools specifically, there's no real "floor" to test against yet:
no tagged/published cat_tools release has cat_tools.routine__parse_arg_types_text (added on cat_tools' unreleased
master, intended as 0.3.0). The floor case is only testable once that's
tagged.
Status
Not scheduled for implementation. This issue exists so the plan doesn't
get lost and so we remember which project/repo this belongs to
(extension_tools, consumer-side — not cat_tools, which is a leaf with no
dependencies of its own). Revisit once:
cat_tools 0.3.0 is tagged/published (unblocks the floor case for this repo), and
the in-flight CI work (no-reinstall test-update GUC mode, pg_tle dependency
testing) has landed, since this axis interacts with both.
See also advanced-extension-testing.md (§ dependency-version testing axis)
and PR #10.
Summary
Our CI matrix only varies the PostgreSQL version. It never validates that we
actually support the oldest version of a dependency we claim to require
(e.g.
META.in.json'scat_tools: 0.3.0floor) — we only ever build/testagainst whatever's current. If the floor drifts out of sync with reality
(newer dependency features get used without bumping the declared floor), CI
won't catch it.
Proposed shape (from prior discussion, not a committed design)
A dependency-version axis, orthogonal to the PG-version matrix, testing each
declared dependency at three points:
META.in.json'sprereqs.Blocking. Catches accidental use of dependency features newer than the
declared floor.
a temporary git-source pin like the one added in Fix cat_tools dependency: install from pinned git SHA, not PGXN #10 for
cat_tools0.3.0). Blocking. Main day-to-day coverage.
or scheduled), early warning for upcoming breakage in the dependency.
To avoid matrix blow-up: run the full PG-version matrix only for the
"released" point; run "floor" and "master" at just the min and max supported
PG versions.
This needs a reusable installer, something like
install-dep <name> <pgxn|git> <version-or-ref> [pg_config], generalized outof the one-off
cat_toolsgit-pinMakefiletarget added in #10.Current blocker
For
cat_toolsspecifically, there's no real "floor" to test against yet:no tagged/published cat_tools release has
cat_tools.routine__parse_arg_types_text(added on cat_tools' unreleasedmaster, intended as 0.3.0). The floor case is only testable once that's
tagged.
Status
Not scheduled for implementation. This issue exists so the plan doesn't
get lost and so we remember which project/repo this belongs to
(
extension_tools, consumer-side — notcat_tools, which is a leaf with nodependencies of its own). Revisit once:
testing) has landed, since this axis interacts with both.
See also
advanced-extension-testing.md(§ dependency-version testing axis)and PR #10.