reactor-bom: the release train that keeps Reactor Core and Reactor Netty in step

What reactor/reactor actually is, and who should depend on it

The repository named reactor/reactor does not contain reactor-core or reactor-netty. The README states plainly that the project is organized into multiple repositories, and that this one hosts a BOM plus transverse issues. The artifacts themselves live in reactor/reactor-core, reactor/reactor-netty, reactor/reactor-addons and reactor/reactor-pool. What you get here is a single pom, published as io.projectreactor:reactor-bom, that pins a compatible set of versions across all of them.

The problem it solves is version drift. Reactor Core, Reactor Netty and the addons do not release in lockstep, so their version numbers are not aligned. The README describes the BOM as a release train with a heterogeneous range of versions curated to work together. Without it, you pick a reactor-core version and a reactor-netty version yourself and find out at runtime whether the pair agrees.

The audience is narrow and specific: teams building on Project Reactor who pull in more than one Reactor artifact, typically through Spring Boot or a framework that already imports the BOM on their behalf. If you use exactly one Reactor artifact and nothing else, the BOM adds an indirection layer for no benefit.

How the release train works: YYYY.MINOR.MICRO-QUALIFIER and chemical codenames

The version scheme is the mechanism. Since Europium, the README states, artifact versions follow YYYY.MINOR.MICRO-QUALIFIER. YYYY is the year of the first GA release in a cycle, MINOR increments per release cycle and lets you tell two cycles apart when they start in the same year, PATCH increments per service release, and QUALIFIER is textual and omitted for GA. So 2025.0.7 is a service release in the 2025 cycle, and 2026.0.0-M1 is a milestone in the next one.

Each train also carries a codename drawn from the periodic table in alphabetical order. The README lists Aluminium for the 3.0.x generation of reactor-core, Bismuth for 3.1.x, Californium for 3.2.x, Dysprosium for 3.3.x and Europium (2020.0) for 3.4.x. The codenames exist for discussion, not for dependency coordinates.

The README also documents a naming break. Up to Dysprosium the BOM used codename-plus-qualifier, so Aluminium-RELEASE was the first GA and Californium-SR1 was a service release. Those map onto the current scheme as YYYY.0.0 and YYYY.0.1 respectively. If you are reading an old build file or an old forum answer, that mapping is the thing to translate.

Importing reactor-bom in Maven and adding reactor-core without a version

Maven needs the BOM in dependencyManagement with import scope. The README gives this exact snippet, and the two details that matter are the dependencyManagement section and the import scope; putting the BOM in a plain dependencies block does not work.

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.projectreactor</groupId>
            <artifactId>reactor-bom</artifactId>
            <version>2026.0.0-M1</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

With that in place, dependencies on Reactor artifacts are declared without a version element. The README shows reactor-core in compile scope and reactor-test in test scope.

<dependencies>
    <dependency>
        <groupId>io.projectreactor</groupId>
        <artifactId>reactor-core</artifactId>
    </dependency>
    <dependency>
        <groupId>io.projectreactor</groupId>
        <artifactId>reactor-test</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>

After a build, the resolved version of io.projectreactor:reactor-core should match whatever the imported BOM pins. If Maven reports a version conflict, something else in your dependency tree is pinning a Reactor artifact directly, and the BOM is not winning.

Gradle: platform() on 5.0+, and the Spring dependency-management plugin before that

Gradle 5.0 and later have native Maven BOM support through the platform keyword inside the dependencies block. The README's example imports the BOM as an implementation platform and then declares reactor-core with no version.

dependencies {
     // import BOM
     implementation platform('io.projectreactor:reactor-bom:2026.0.0-M1')

     // add dependencies without a version number
     implementation 'io.projectreactor:reactor-core'
}

Older Gradle versions have no core BOM support. The README points at Spring's gradle-dependency-management plugin, applied from the Gradle Plugin Portal, with the version to be checked and changed if a newer one exists.

plugins {
    id "io.spring.dependency-management" version "1.0.11.RELEASE"
}

The BOM is then imported through the plugin's dependencyManagement block, and dependencies are declared in the older compile configuration without a version. This is the path the README documents for Gradle 4.x and earlier; if you are on Gradle 5 or newer, the platform keyword is the shorter route.

Where the BOM stops helping: transitive pins and milestone versions

A BOM only supplies defaults. The README is explicit that it provides default artifact versions to use whenever the corresponding dependency is added to a pom without an explicitly provided version. The moment a transitive dependency or a parent pom pins reactor-core to a specific version, that pin wins, and the imported BOM becomes decoration. Spring Boot users hit this regularly, because the Boot parent manages Reactor versions itself. Importing reactor-bom underneath a Boot parent does not necessarily override it.

The other sharp edge is the qualifier. The README's own examples use 2026.0.0-M1, a milestone, while 2025.0.7 is the current service release in the previous cycle. Milestones are what the documentation demonstrates, but they are not GA, and the README does not describe a support policy for them. Choosing a train is therefore a real decision, not a copy-paste one.

Finally, this repository is not where you file bugs about behavior. The README says it is for hosting the BOM and transverse issues only, and that most issues and PRs belong in the repository of the specific artifact. A stack trace from reactor-netty is not a reactor/reactor issue.

Alternatives: pinning versions yourself, or letting a framework manage them

The direct alternative is to declare explicit versions on every Reactor artifact. That is more verbose and it is exactly the drift problem the BOM exists to prevent, but it is also fully transparent: nothing overrides your choice, and a version bump is a visible diff. For a project with one Reactor dependency, this is the simpler arrangement.

The other alternative is to let a framework manage Reactor for you. Spring Boot ships its own managed dependency set that includes Reactor, so a Boot application often gets a curated, tested combination without importing reactor-bom at all. The difference in approach matters: the framework's set is chosen and tested against the framework, while reactor-bom is chosen by the Reactor project against itself. If your framework already manages these artifacts, adding the BOM on top creates two sources of truth rather than one.

Licence, maintenance and what upgrading a train costs

The repository is Apache-2.0, and the README links the Reactor-wide licence at the reactor/.github repository. Apache-2.0 is a permissive licence with a patent grant, and it imposes no copyleft obligation on your application. This is a description of the licence identifier, not legal advice; if you redistribute modified Reactor artifacts, read the licence text yourself.

The repository is not archived, and the last push was on 2026-09-23. Recent releases listed are 2026.0.0-M1 and 2025.0.7, both dated 2026-08-24, and 2025.0.6 dated 2026-06-08. The cadence suggests service releases within a cycle plus milestones for the next one.

The upgrade cost is concentrated in one line: the version on the BOM import. Because the BOM is a release train with a heterogeneous range of versions, moving from 2025.0.6 to 2025.0.7 can move several artifacts at once, including Reactor Netty, which sits under your HTTP stack. That is the trade: one version to change, and several libraries changing with it. The README does not document a rollback procedure, so the practical rollback is reverting that single line and rebuilding.

Editorial conclusion

Adopt the BOM if you already use two or more Reactor artifacts and want one version to manage instead of several; skip it if you depend on reactor-core alone, since a single explicit version is easier to reason about. Before switching, check which release train your Spring Boot or framework version aligns with, and verify that every io.projectreactor artifact in your build resolves under the imported BOM rather than a transitive pin.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. reactor/reactor on GitHub
4. README
5. Releases