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

> Spring Boot's README is short and mostly links outward, to docs.spring.io, the wiki release notes and the issue tracker. What it does state is a four-item goal list, one item of which is a promise of no code generation and no XML, and a build section that says JDK 25 is needed and that the command for trying the latest locally will not run any tests.

**spring-projects/spring-boot** — Spring Boot helps you to create Spring-powered, production-grade applications and services with absolute minimum fuss.

- Repository: https://github.com/spring-projects/spring-boot
- Website: https://spring.io/projects/spring-boot
- Stars: 81,497 · Forks: 43,174
- Language: Java
- License: Apache-2.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/spring-projects-spring-boot

## 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 four words that are easy to skim past: absolutely no code generation and no requirement for XML configuration. The rest of the file is a single Java class, and it is small enough to read in full:

```java
@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 no-code-generation promise is about your application, not about the project. The repository itself carries buildSrc/, build-plugin/, configuration-metadata/, loader/ and antora/, so a contributor expecting a build with no generated code finds a build with custom Gradle plugins in it. The promise is real and it is also narrower than it sounds.

## 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.1.1 and v4.2.0-M1 both carry 2026-08-20, twenty minutes apart, and v4.2.0-M2 follows on 2026-09-24. The repository is not archived and the last commit to main is dated 2026-09-25, so the branch is moving while the newest version number is a pre-release rather than a release.

Consequence: anything that resolves the highest version it can find takes a milestone. 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 last stable version in the visible list is v4.1.1, and upgrading to 4.2 is a decision with a documented cost: the project points upgraders at release notes in its wiki rather than at a migration guide in the repository.

## 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:

```shell
$ ./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:

```shell
$ ./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 subordinate clause 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 single command in the README that runs all four, and the one command the README does give you 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. The file is small and the instruction is short, which is why neither is wrong, and the combination is still a first-failure experience for the most common build problem on the project.

## 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 bar is deliberately high, which keeps the tracker clean and puts the work on the person whose build is already failing. Someone who cannot get a project to start often cannot produce a reproducing test, so the hardest reports to triage are the ones most likely to be real. A report carrying all four items moves; a report carrying a stack trace alone tends to sit.

## 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-M2, a milestone, so anything that resolves the highest version number lands on a pre-release rather than on v4.1.1. 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 a reproducing test case, which is a high bar to clear when the build you are reporting is already broken.

## FAQ

### What is Spring Boot used for?

It helps you create Spring-powered, production-grade applications and services. You can build stand-alone Java applications started with java -jar, or more traditional WAR deployments, and it ships non-functional features such as embedded servers, security, metrics, health checks and externalized configuration.

### Is Spring Boot for the frontend or the backend?

The backend. The one worked example in the README is a Java class annotated with @RestController and @SpringBootApplication, exposing a single @RequestMapping for the root path and started through SpringApplication.run in its main method. Nothing in the file concerns itself with rendering in a browser.

### How do I install Spring Boot?

You do not install it as a program. Installation instructions and a getting started guide live in the reference documentation at docs.spring.io, and the README says you do not need to build from source to use it. To work on it instead, you need JDK 25 and the Gradle wrapper in the repository root.

### Is Spring Boot still relevant in 2026?

The repository is not archived, the last commit to main is dated 2026-09-25, and there were releases in August and September 2026. The visible version line is 4.x, with v4.1.1 as the newest stable release and v4.2.0-M2 as the newest tag overall.

## Sources

- [Official documentation](https://spring.io/projects/spring-boot)
- [Official README](https://github.com/spring-projects/spring-boot#readme)
- [Project repository](https://github.com/spring-projects/spring-boot)
- [Release notes](https://github.com/spring-projects/spring-boot/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spring-projects-spring-boot