How to test multiple dependency version ranges (< v"1" and ≥ v"1") in GitHub CI?

General Usage
,
1

I maintain a Julia package that supports multiple major versions of one of its dependencies. The dependency defines:

get_version()::VersionNumber

and my tests contain logic like:

if get_version() >= v"1"
    # test new behavior
else
    # test legacy behavior
end

My package supports both ranges, and my Project.toml has:

[compat]
DepPkg = "0.9, 1"

So I want CI to test both cases:

  • one job using DepPkg < v"1" (e.g. latest 0.9.x)
  • one job using DepPkg ≥ v"1" (latest 1.x)

Current CI setup

My current GitHub Actions CI only tests across Julia versions, OS, and architecture:

strategy:
  fail-fast: false
  matrix:
    version:
      - '1.10'
      - '1.11'
      - '1.12'
      - '1.9'
      - 'nightly'
    os:
      - ubuntu-latest
      - macOS-latest
      - windows-latest
    arch:
      - x64
      - x86

and runs:

- uses: julia-actions/julia-buildpkg@v1
- uses: julia-actions/julia-runtest@v1

This only tests the dependency version resolved by normal Pkg resolution (usually the newest compatible version).

What I want to achieve

I want CI to explicitly test both dependency version ranges:

  • Job A: resolve DepPkg to < v"1"
  • Job B: resolve DepPkg to ≥ v"1"

while keeping my package compat as:

DepPkg = "0.9, 1"

Questions

  1. What is the recommended way to test multiple dependency version ranges in CI?

    Specifically:

    • Should I add a matrix entry for dependency version ranges?
    • Should I modify [compat] dynamically in CI?
    • Should I explicitly Pkg.add(PackageSpec(...)) before tests?
    • Should I use separate test environments?

  2. How does this interact with committed Manifest.toml files (if present)?

  3. Is there an established best practice used by major Julia packages for testing across dependency major versions?

Constraints / goals

  • Keep normal Project.toml compat broad ("0.9, 1")
  • Avoid maintaining multiple test projects if possible
  • Ensure CI reproducibly tests both code paths
  • Use standard julia-actions where possible

Related context

I understand that Pkg resolves only one version per environment, so I assume this requires separate CI jobs with different resolution constraints. I’m mainly looking for the cleanest and most idiomatic way to do this.

2

Here’s one example: Onda.jl/.github/workflows/CI.yml at b8b7720549c35cb57ee587b30a1b610065304253 · beacon-biosignals/Onda.jl · GitHub