Spring Boot: four stated goals, a release candidate as the newest tag, and a build command that runs no tests

Four stated goals, one of which is a promise about XML and code generation

The README commits to a faster and widely accessible getting-started experience, to being opinionated but stepping aside once requirements diverge, to shipping the non-functional features that large classes of projects share, and to a goal that is easy to skim past: absolutely no code generation and no requirement for XML configuration. The README's one code sample is a single Java class, small enough to read in full:

@RestController
@SpringBootApplication
public class Example {

	@RequestMapping("/")
	String home() {
		return "Hello World!";
	}

	public static void main(String[] args) {
		SpringApplication.run(Example.class, args);
	}

}

Three annotations, one method, and a main that hands the class to SpringApplication.run. There is no bean XML, no schema, and nothing to generate before it runs.

Consequence: the goal is stated for people using Spring Boot. The repository itself carries buildSrc/, build-plugin/, configuration-metadata/, loader/ and antora/, so the project's own build is a substantial Gradle build.

Goal two is written around the assumption that you will outgrow the defaults

The second goal is not a feature. It says Spring Boot should be opinionated but get out of the way quickly as requirements start to diverge from the defaults. Divergence is designed for, not treated as a failure of the framework, and the third goal supplies the list of what the defaults cover: embedded servers, security, metrics, health checks and externalized configuration.

Consequence: the defaults you end up fighting are meant to be replaced, which means every one of them is a decision you will eventually own. The README names the five areas the framework covers and says nothing about the knobs to reach for when one does not fit, so the escape hatch is documented as a principle rather than as a set of switches, and finding the right one is a trip to the How-to's.

The newest tag is a milestone, published the day after a patch release

Three releases are visible: v4.2.0-RC1, v4.1.2 and v4.0.9, all dated 2026-10-22. The repository is not archived and the last push is dated 2026-11-02, so the branch is moving while the highest version number, 4.2.0-RC1, is a pre-release rather than a final release.

Consequence: anything that resolves the highest version it can find takes a release candidate. A build pinned to the newest tag is running a pre-release, and a dependency management file that sorts versions lexicographically rather than by release status can end up there without saying so. The latest stable version in the visible list is v4.1.2, and the README points anyone upgrading to the release notes in the project's wiki.

The build is Gradle, the local publish target is a Maven cache, and neither runs tests

Building from source needs JDK 25 and the Gradle wrapper. Two commands are given, and the difference between them is the whole point of the section:

$ ./gradlew publishToMavenLocal

That one builds all modules and publishes them to your local Maven cache, and the next sentence says it will not run any of the tests. The alternative is:

$ ./gradlew build

Consequence: the documented way to try the latest version locally is also the way to get it without a single test executing, and the file mentions that in a single plain sentence rather than as a warning. A change that breaks something can sit in a local Maven repository and be picked up by a downstream build that trusts the artefact, which is exactly the state the project's own first goal, a fast and accessible getting started, quietly works against.

Four test modules sit at the top level, so run the tests has four answers

The tree separates concerns by directory rather than by Maven-style module paths. There is core/, loader/, starter/, platform/, module/, config/, cli/ and buildpack/, and beside them four distinct test trees: integration-test/, smoke-test/, system-test/ and test-support/. Build tooling has its own directories in buildSrc/ and build-plugin/, and documentation has antora/ and documentation/.

Consequence: a contributor looking for the test suite finds four of them and no command in the README that is described as running all four, and publishToMavenLocal, the command given for trying the latest, runs none of them. Two directories for documentation, antora/ and documentation/, sit side by side as well, so working out which one is current is a small task repeated by every new contributor. The tree also splits the runtime in a way that is worth noticing before you file anything: loader/ and starter/ are separate from core/ and platform/, which is a reasonable shape for a project of this size and a poor map for a newcomer who only knows the framework's name.

JDK 25 arrives in one sentence, and the SDKMAN pin in the root is never connected to it

The build section is three sentences. You do not need to build from source to use Spring Boot. If you want to try out the latest, it can be built with the Gradle wrapper. And you also need JDK 25. There is no version matrix, no table of supported JDKs and no note about what happens on an older one. Meanwhile the root of the repository carries a .sdkmanrc file, which is the SDKMAN version pin, and nothing in the README mentions it.

Consequence: the pin and the instruction are two unconnected objects, so a contributor who reads the README installs whatever JDK their distribution defaults to, discovers the failure at the Gradle step, and has to find the .sdkmanrc themselves.

A bug report is expected to carry a version, an operating system, a JVM and a test case

The reporting section is longer than the getting-started section. Search the issue tracker before filing. If the issue is not there, create one. Provide as much information as possible, and the file says specifically that they want to know the Spring Boot version, the operating system and the JVM version you are using. Paste code or stack traces in Markdown. And, if possible, try to create a test case or project that replicates the problem and attach it to the issue.

Consequence: the test case is requested only "if possible", so the version, operating system and JVM are the baseline for a report.

Editorial conclusion

Use Spring Boot when you want a Spring application that starts as a runnable jar with embedded servers, metrics and health checks already wired, and read the How-to's rather than the README, because the README answers none of the configuration questions. Three things to check first. The newest tag is v4.2.0-RC1, a release candidate, so anything that resolves the highest version number lands on a pre-release rather than on v4.1.2. Building from source needs JDK 25 through the Gradle wrapper, and publishToMavenLocal will not run a single test, so a local snapshot is not evidence that anything works. And the issue tracker asks for a version, an operating system, a JVM version and, if possible, a reproducing test case, which is a high bar to clear when the build you are reporting is already broken.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes