[kushagragarg55]

Resolves #300 (the remaining checklist item: add the Spring Boot and Spring gRPC versions to the Gradle samples workflow).

What this does

The Gradle samples now build against a small version matrix instead of a single hardcoded version, so they double as compatibility tests. The workflow runs the samples on the latest stable pair (Spring Boot 4.1.1 / Spring gRPC 1.1.1) and the latest snapshot pair (4.1.2-SNAPSHOT / 1.1.2-SNAPSHOT), each on Java 17 and 25. Java 24 handling for the Kotlin sample is preserved.

How the versions are injected

Per the discussion on the issue, the versions live in the sample build files using Boot's own tooling rather than an init script:

• bootVersion in samples/gradle.properties feeds the Spring Boot Gradle plugin (id 'org.springframework.boot' version "$bootVersion") and is overridable with -PbootVersion.
• The previously orphaned springGrpcVersion variable (dead since the starters moved into Spring Boot) now overrides the Boot-managed spring-grpc.version through ext, but only when -PspringGrpcVersion is passed. Without it, Boot's pinned version wins, so a plain ./gradlew build behaves exactly as before.

The workflow passes both as a matrix axis, and fail-fast: false lets each cell report independently.

Verification

I ran the matrix on a fork. All four cells build and test green, and dependencyInsight confirms each cell resolves the intended version:

Java	Boot	spring-grpc-core resolved
17	4.1.1	1.1.1
25	4.1.1	1.1.1
17	4.1.2-SNAPSHOT	1.1.2-SNAPSHOT
25	4.1.2-SNAPSHOT	1.1.2-SNAPSHOT

In the snapshot cells, Boot's pinned 1.1.1 is overridden to 1.1.2-SNAPSHOT, which confirms the ext override takes effect.

The mechanism also makes a mixed cell (stable Boot with snapshot Spring gRPC) a one-line matrix addition if you want to add it later.

Testing

Completed the test on a forked test branch - https://github.com/kushagragarg55/spring-grpc/actions/runs/37318002448