Staying Current — and What You Actually Built

This Guide Will Be Wrong Eventually

Every guide in this roadmap has pinned specific facts: Spring AI 2.0.0, Spring Boot 4.1, exact class names verified against live reference docs, honest hedges on Embabel and LangChain4j version numbers that were already uncertain at the time of writing. Some of that will be stale by the time you're reading this — not because anything here was careless, but because that's what building on a fast-moving stack means. This closing guide isn't one more API to learn; it's the system for handling everything before it, as it keeps changing.

---

1. Spring AI's Actual Release Rhythm

Worth knowing precisely, not just "it moves fast": 1.0 went GA in May 2025, 1.1 in November 2025, and 2.0.0 — the version this roadmap targets — on June 12, 2026, built for Spring Boot 4.0/4.1 and Spring Framework 7. Patch releases land roughly every two to four weeks. The 1.1.x line didn't stop existing the day 2.0 shipped — it kept receiving patches specifically for teams still on Spring Boot 3.x, exactly the fallback path this roadmap's first guide described for anyone not ready to move to Boot 4 yet.

Three sources cover this without drowning in noise:

1. spring.io/blog — every release announcement, with migration notes for anything that actually breaks compatibility.
2. github.com/spring-projects/spring-ai/releases — the detailed, unfiltered changelog, useful when the blog summary isn't specific enough about whether a change touches code you actually wrote.
3. github.com/spring-projects/spring-ai/discussions — where "is this a bug or intended" gets settled by people who'd know.

---

2. The Same Discipline for Embabel and LangChain4j

Both frameworks got explicit hedges throughout this roadmap — uncertain version numbers, experimental-module warnings, "check current docs" callouts instead of confidently-asserted syntax. That wasn't hedging for its own sake; it's the honest state of two projects moving faster than Spring AI itself. Apply the same three-source pattern:

• Embabel: github.com/embabel/embabel-agent/releases, the project's Discord (linked from the repo) for faster-moving discussion than GitHub issues, and re-cloning the official templates periodically rather than trusting a build.gradle you wrote months ago.
• LangChain4j: github.com/langchain4j/langchain4j/releases and the langchain4j-examples repo, which tends to reflect current best practice faster than any single blog post does.

---

3. A System for Upgrading Without It Becoming a Project

Reading a changelog and actually upgrading are different amounts of risk. A reasonable process, scaled to how much a given release actually changes:

1. Version-pin deliberately. The Spring AI BOM (this roadmap's very first setup guide), and equivalent version properties for Embabel and LangChain4j, mean an upgrade is a single number changing in one place — not a dependency-by-dependency hunt.
2. Read the migration notes before touching the number. A patch release (2.0.0 → 2.0.1) is usually safe to take without much ceremony. A minor or major line change (1.1 → 2.0, the exact jump this roadmap's guides walked through) deserves an actual read of what changed — this roadmap's own experience updating from a "1.1 GA" assumption to "2.0 GA, with a renamed evaluator class and a corrected observability property name" mid-writing is a live example of exactly the kind of thing a migration note would have caught faster than discovering it by testing.
3. Run your test suite before promoting. This roadmap's fourth phase built exactly the tool for this — the @SpringBootTest golden-set evaluation suite from the Agent Evaluation guide. Run it against the new version in a branch before merging the upgrade; a regression in grounding or relevancy is a much better thing to catch in CI than in production.
4. Upgrade on your own schedule, not the same day. Nothing about this roadmap's 2.0 migration required same-day adoption — 1.1.x kept receiving patches specifically so teams wouldn't need to rush. Treat a major version bump as a planned piece of work with its own review, not something to merge reflexively the morning it's announced.

---

What You Actually Built

Step back from the version numbers for a moment. Across seven phases, this roadmap built one running example — a support agent for a fictional fintech company — and kept adding to the exact same codebase:

• A ChatClient making its first calls (phase one), then structured, memory-backed, RAG-grounded (phases two and three)
• Tool calling, hand-rolled multi-step reasoning, MCP interoperability, and automated evaluation (phase four)
• The same agent's genuinely complex branching logic, rebuilt on Embabel's planner once hand-written control flow stopped scaling (phase five)
• A second, declarative implementation of the same ideas in LangChain4j, and proof the two frameworks coexist in one application (phase six)
• Streaming, full observability, cost control, and now this closing discipline for keeping all of it current (phase seven)

That's not a coincidence — it's this roadmap's own capstone project, an AI-Powered Customer Support Agent, built one guide at a time rather than handed to you all at once. If you followed along with real code rather than just reading, you're closer to having it than a blank project would suggest: ChatClient with persistent memory, a PDF-backed RAG pipeline, tool-calling for live order lookups, an MCP server exposing those tools externally, a streaming endpoint, Micrometer + Grafana watching all of it, and — as a stretch goal worth actually attempting — the escalation workflow re-implemented as an Embabel @Agent so it replans on failure instead of retrying blindly.

---