Maven: Versions & Release History

The history page states the policy in one sentence: the Maven team maintains the last version of the last two series of GA releases, which on 2026-10-16 are 3.10.0 and 3.9.16. Everything older has reached its end of life: the team provides no bug or security fixes and adds no features. Maven does not distinguish "end of life" from "end of support" and uses only the first term. The download page calls 3.10.0 "the recommended version for all users" and 3.9.16 "the previous stable minor release", still maintained, with users encouraged to upgrade. Maven 4.0+ is listed separately as "not yet GA".

Three end-of-life dates are worth remembering:

Source: Maven: Releases History

Source: Maven: Releases History, Maven 3.8.x and before

Source: Maven: Downloading Apache Maven

The Java floors in the figure are the ones the history page groups by line: 2.0 to 2.1 need Java 1.4, 2.2 needs Java 5, 3.0 and 3.1 need Java 5, 3.2 needs Java 6, 3.3 to 3.8 need Java 7, 3.9 and 3.10 need Java 8, and Maven 4 needs Java 8 up to 4.0.0-alpha-12 and Java 17 from 4.0.0-alpha-13 on (the plugin compatibility plan records the vote that moved Maven 4 to Java 17 in February 2024). The figure is original; its dates were read from the history page, and its bars run from the first to the last release that page lists for a line.

Source: Maven: Releases History, Maven 3.10.x+

The table lists the releases you are likely to meet in a project or in a book, with the change that justifies their place. The descriptions come from the official release notes; where a release’s notes only point to the issue tracker, the row says so instead of filling the gap from memory.

The Central metadata for org.apache.maven:apache-maven was read on 2026-10-16 and its newest version is 4.0.0-rc-7: there is no 4.0.0 GA yet, so every Maven 4 statement in this section is labelled "release candidate". The pages Maven 4: What’s New and Migrating to Maven 4 cover what it changes.

Source: Maven: Releases History, Maven 4.0+

Source: Maven 3.10.0 release notes: Notable Changes

Source: Maven 3.9.0 release notes: Notable Core Improvements

Source: Maven 3.8.1 release notes

Source: Maven 3.5.0 release notes: Overview about the changes

Source: Maven 3.3.1 release notes: Core Extensions

Source: Maven 3.2.1 release notes: Highlights

The floors above are for the JVM that runs Maven. They are not the Java of your project: the download page says the 3.10 line "still allows you to build against 1.3 and other JDK versions by using toolchains", and the Maven 4 article says Java 17 "is only needed to run Maven" while projects compile against older versions with the same compiler plugin configuration as before. Setting JAVA_HOME to an older or newer JDK changes the first and not the second. The banner shows which JDK Maven picked: 3.10.0 on a JetBrains Runtime 17 and 4.0.0-rc-7 on a JetBrains Runtime 21, both started with JAVA_HOME pointing at them.

The Maven 4 release candidate needs Java 17 or later; a JDK 8 or 11 start was "not run here" (only JDK 17, 21 and 26 were installed), so no error message for that case is reproduced. How a project asks for a specific JDK for compiling and testing is covered in Compiling & Toolchains. Ant 1.10 needs Java 8 to run (see its history page) and Gradle 9.8.1 needs Java 17 or later to run, with toolchains for the build (see Gradle: Installation).

Source: Maven: Downloading Apache Maven

Source: Maven 4: Required Java version

Maven’s core and its plugins are released separately ("the core release is independent of plugin releases", say the notes of every release), so the question "which plugin works with which Maven" has its own answer: the Maven Plugins Compatibility Plan. It sets the minimum Java and the minimum Maven that plugins and shared components may require. Its milestones, as written on the page:

The history page sums it up: "currently, plugins provide Maven API compatibility down to 3.9.0". The practical rules are to stay on 3.9.0 or later, to pin every plugin version, and not to expect a new plugin release to work on a Maven that is end of life. The plugin versions that were the latest stable ones on Maven Central on 2026-10-16 (pre-releases such as the 4.x betas excluded) are used across this section:

All versions in the table come from the maven-metadata.xml files on Maven Central read on 2026-10-16 (for the plugins with a pre-release newer than the stable one, the newest stable version in the file). The 4.x plugin lines are betas that require Maven 4. The check below asks Maven 3.10.0 and 3.9.16 to run the compiler plugin 4.0.0-beta-5 directly (the project is a small tidepool-engine POM with commons-csv and picocli):

The 3.9.16 run printed the same three lines with "current version 3.9.16". The message is Maven’s own plugin-prerequisite check, so a plugin that needs a newer Maven than you run fails before it does anything. The same goal on Maven 4.0.0-rc-7 (release candidate) got further and stopped at a different requirement: Maven 4 needs to know where the project root is.

After mkdir .mvn in the project directory (an .mvn directory marks the root; the alternative is root="true" on the model), the same command succeeded:

When you do not pin a plugin version, the version comes from the default lifecycle bindings of the Maven you run, and those move with the Maven release. The table was built by running help:effective-pom (plugin 3.5.2) on the same POM, which declares no plugin versions, with the three Maven versions and reading the plugins in build/plugins:

Two consequences follow. A build that never pinned plugins changes behaviour when you move from 3.9.16 to 3.10.0 even if you change nothing else, which is the argument for the <pluginManagement> section of the parent POM (see Plugins & Their Configuration). And the 3.9.16 super POM also managed maven-antrun-plugin 3.1.0, maven-assembly-plugin 3.7.1, maven-dependency-plugin 3.7.0 and maven-release-plugin 3.0.1 in a <pluginManagement> section, which 3.10.0 removed (next section), so a build that relied on those versions without declaring them gets whatever resolves instead: with no version, the plugin metadata decides, which is exactly the situation Maven’s validation has warned about since Maven 3.

Source: Maven Plugins Compatibility Plan: Maven Plan

Source: Maven: Releases History, plugin compatibility

The 3.10.0 notes list the "potentially breaking core changes" for a migration from 3.9.x. Each item below says what it is, what it looks like and what to do; the ones marked "run" were reproduced here with the three Maven versions on a small POM.

Maven 4.0.0-rc-7 is the seventh release candidate. Its release notes say it is "expected to be the last before the Maven 4.0.0 GA release", with GA aimed at "the coming weeks, pending community feedback", and that 4.0.0-rc-4 already said it aimed to be the last. Both notes recommend the upgrade tool, mvnup check to detect problems and mvnup apply to fix them (the tool is in the 4.0.0-rc-7 distribution next to mvn, as the installation page lists). Because the 3.10 line already moved to the same Resolver lineage, the jump from 3.10 to 4 is smaller than the jump from 3.9 would have been; the largest remaining changes are the Java 17 requirement, the new POM model version 4.1.0 and the consumer POM, which the three Maven 4 pages describe. Plan the move with Migrating to Maven 4; this page does not repeat it.

Source: Maven 4.0.0-rc-7 release notes: Upgrading from Maven 3

Source: Maven 4: What’s new?

Apache Maven 2 Effective Implementation (Packt, 2009) targets Maven 2.2. This section’s pages are written against the current documentation and name the old practice only where a reader of the book will trip over it:

Source: Apache Attic: Continuum

Source: Apache Attic: Archiva

Source: Maven 3.x Compatibility Notes: Plugin Metaversion Resolution

Source: Sonatype: OSSRH Sunset

Source: Apache Maven Reactor Plugin (RETIRED)

Ant’s releases are a single 1.10 line on Java 8 with no plugin ecosystem to keep in step; Gradle ties a build to its wrapper version and publishes a compatibility matrix between Gradle, Java and Kotlin; Maven ties a build to the plugin versions it pins and to the support window of the core. The equivalent of "which tool version do I run" is therefore the wrapper properties in Gradle and Maven (see Maven Wrapper) and the installed directory in Ant. The cross-tool comparison is in Comparing Ant, Maven and Gradle.