Spring Boot current version jak śledzić aktualną stabilną wersję

Najnowszą stabilną wersję Spring Boota, czyli to, co internauci wpisują jako „spring boot current version”, sprawdzisz najszybciej na start.spring.io oraz w Maven Central. W chwili publikacji najnowsza linia to 3.5.x, a czwarta wersja wnosi Spring Framework 7 i bazowe Java 17. Metadane z Maven Central czytasz programowo, więc wersja w twoim buildzie się nie zestarzeje.

Jak odczytać spring boot current version z metadanych Maven Central

Maven Central trzyma dla każdego artefaktu plik maven-metadata.xml. Dla samego Spring Boota leży on pod adresem:

https://repo1.maven.org/maven2/org/springframework/boot/spring-boot/maven-metadata.xml

W środku znajdziesz trzy rzeczy, które cię interesują. <latest> to ostatnia opublikowana wersja, <release> to ostatnia wersja bez dopisku SNAPSHOT, a <versions> to pełna lista. Jeśli chcesz mieć pewność, że nie trafiłeś na wydanie milestona albo release candidate, przejedź po liście i odfiltruj wpisy z literami.

Prosty test w terminalu:

curl -s https://repo1.maven.org/maven2/org/springframework/boot/spring-boot/maven-metadata.xml | grep '<release>'

Dostajesz jedną linijkę i już wiesz, jaka jest aktualna stabilna wersja. Jeśli dopiero porządkujesz podstawy, Spring Boot co to jest i dlaczego wyjaśnia, po co w ogóle śledzić te numery. Ta metoda działa też w skrypcie na serwerze CI, gdzie nie ma przeglądarki.

Drugie źródło to generator projektów. Wywołanie:

curl -s https://start.spring.io/metadata/client | jq '.bootVersion'

zwraca listę wersji, które start.spring.io proponuje przy tworzeniu nowego projektu. To najbliżej tego, co zobaczy osoba zaczynająca zabawę ze Springiem. Jeśli chcesz przejść od pierwszego projektu do działającej aplikacji, Spring Boot zero to hero porządkuje kolejne kroki.

Trzecie źródło to strona releases w repozytorium na GitHubie i zakładka projektu na spring.io. Odpowiedź na pytanie o spring boot current version jest w tych miejscach identyczna, różni się tylko format.

Czwarte miejsce, o którym mało kto pamięta: endoflife.date/spring-boot. Zbiera wersje, daty wydania i daty końca wsparcia w jednej tabeli. Przydaje się, gdy musisz szybko uzasadnić szefowi, dlaczego warto ruszyć z aktualizacją.

Co oznaczają numery wersji Spring Boota i kiedy wychodzi nowa

Numer wersji czytasz od lewej: MAJOR.MINOR.PATCH. W zapisie 3.5.4 trójka to major, piątka to minor, czwórka to patch.

Patch wychodzi co kilka tygodni i zawiera poprawki błędów oraz łaty bezpieczeństwa. Minor pojawia się mniej więcej co pół roku, w maju i listopadzie. Major to rzadkość i duże wydarzenie - Spring Boot 4.0 pojawił się w listopadzie 2025 i przyniósł Spring Framework 7. Jeśli mylisz te dwa projekty, Czym się różni Spring od Spring Boot porządkuje zależność.

Po numerze mogą stać dopiski:

• M1, M2 - milestone, czyli wczesny podgląd
• RC1 - release candidate, kandydat do wydania
• SNAPSHOT - build z gałęzi, zmienia się z dnia na dzień

Do produkcji bierzesz wyłącznie wersje bez dopisków. Milestone'y i RC nadają się do testów na bocznym branchu, gdy chcesz wcześniej sprawdzić, czy twoja aplikacja się nie wysypie.

Daty wydań nie musisz zgadywać. Zespół Springa publikuje plan na GitHubie i trzyma się go dość konsekwentnie. Wystarczy raz na kwartał zajrzeć do kalendarza i zaplanować aktualizację, zamiast reagować panicznie, gdy na skanerze CVE wyskoczy alert. Jeśli szukasz szerszego zestawienia, najnowszy Spring Boot i informacje o stabilnych wydaniach znajdziesz w osobnym omówieniu.

Ile trwa wsparcie i kiedy twoja wersja przestaje je dostawać

Każda linia minor dostaje 12 miesięcy wsparcia OSS. Przez ten czas wychodzą patche z poprawkami bezpieczeństwa. Potem możesz kupić wsparcie komercyjne, które wydłuża ten okres o kolejne lata.

W praktyce wygląda to tak, że linia 3.5.x trzyma wsparcie OSS do połowy 2026, a 3.4.x skończyło je pod koniec 2025. Sprawdzasz to raz i wiesz, ile masz czasu.

Dlaczego to ma znaczenie? Bo po zakończeniu wsparcia nie dostajesz już łat na podatności. Jeśli twoja aplikacja przetwarza dane osobowe albo płatności, zostajesz z luką, której nikt nie załata. Audytorzy w firmach z branży finansowej patrzą na to w pierwszej kolejności.

Załóż sobie bufor trzech miesięcy. Skoro linia traci wsparcie w czerwcu, migrację planuj na marzec. Dzięki temu nie robisz jej w panice na tydzień przed deadlinem, razem z trzema innymi zadaniami.

Jak zautomatyzować pilnowanie wersji w repozytorium

Ręczne zaglądanie na stronę działa, dopóki pamiętasz. Po dwóch miesiącach zapominasz. W wielu zespołach w Polsce aktualizacja zależności czeka w backlogu na lepszy moment, a ten moment nie nadchodzi. Lepiej wrzucić to do pipeline'u.

Dependabot w GitHubie konfigurujesz kilkoma linijkami:

version: 2
updates:
  - package-ecosystem: maven
    directory: "/"
    schedule:
      interval: weekly
    open-pull-requests-limit: 3

Dostajesz pull request z podbiciem wersji, uruchamiasz testy i mergujesz. Renovate działa podobnie i daje więcej opcji grupowania. Obie wtyczki rozumieją zarówno Maven, jak i Gradle.

W samym Mavenie masz plugin versions, który wypisze ci, co da się podbić:

mvn versions:display-dependency-updates

W Gradle odpowiednikiem jest task dependencyUpdates z pluginu ben-manes. Obie komendy wrzucasz do nocnego joba i codziennie rano masz raport. Nie musisz wtedy ręcznie sprawdzać spring boot current version w przeglądarce.

Osobna sprawa: trzymaj wersje w jednym miejscu. W Gradle to plik libs.versions.toml, w Mavenie właściwość <spring-boot.version> albo parent. Wtedy zmiana to jedna linijka, a nie polowanie po piętnastu modułach.

Nie aktualizuj wszystkiego naraz. Podbij Spring Boota osobno, a biblioteki trzeciej strony osobno. Kiedy coś się zepsuje, od razu wiesz, co sprawdzić.

Migracja na nowszą linię krok po kroku

Zacznij od release notes i migration guide dla każdej wersji, przez którą przeskakujesz. Pomijanie ich to najczęstszy powód, dlaczego aktualizacja zajmuje trzy dni zamiast trzech godzin. Przed skokiem sprawdź, Jaka jest najnowsza wersja Spring Boot i jakie zmiany ze sobą niesie.

Najpierw podbij do najwyższego patcha w obecnej linii. Jeśli siedzisz na 3.4.2, przejdź na 3.4.12. To osobne wdrożenie, bez zmian w kodzie. Jeśli coś pęknie, problem jest w patchu, nie w migracji.

Potem skok o jedną linię minor. Z 3.4 na 3.5, nie z 3.4 na 4.0. W Mavenie zmieniasz wersję w parent:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.5.4</version>
</parent>

Uruchom pełny zestaw testów, w tym testy integracyjne. Te drugie wyłapią zmiany w konfiguracji, których testy jednostkowe nie widzą.

Na czas migracji dodaj spring-boot-properties-migrator. Ta biblioteka czyta twoje stare klucze w application.yml i wypisuje w logach, które z nich trzeba zastąpić. Po zakończeniu migracji usuwasz ją z zależności.

Przy skoku na 4.0 sprawdź wersję Javy osobno. Spring Boot 4 wymaga minimum Java 17, a wiele bibliotek trzeciej strony dopiero nadgania wsparcie dla nowszych wydań. Jeśli twój stos zawiera starą bibliotekę, która nie ma nowej wersji, zatrzymaj się i policz koszt.

Kiedy zostać na starszej wersji i jak to uzasadnić

Zostanie na starszej wersji bywa sensowne, ale tylko wtedy, gdy znasz powód i datę wyjścia z tego stanu.

Jeśli twoja aplikacja stoi na serwerze aplikacyjnym z certyfikacją, a producent nie wypuścił wsparcia dla Spring Boota 3.5, nie masz wyboru. Jeśli używasz biblioteki, której autor porzucił projekt w 2021 roku, migracja oznacza przepisanie modułu. Czasem lepiej to zaplanować na kolejny kwartał niż robić na wczoraj.

Co robić w takiej sytuacji:

1. Przypnij konkretną wersję w pliku builda i zapisz, dlaczego.
2. Ustaw alert na CVE dotyczące twojej wersji.
3. Wyznacz datę, do której migracja ma być gotowa, i wpisz ją do backlogu jako zadanie, nie jako marzenie.

Brak decyzji to też decyzja, tylko podejmowana przez kogoś innego. Zwykle przez osobę, która trzy miesiące później gasi incydent.

Najczęstsze pytania

Jaka jest najnowsza wersja Spring Boot?

Najnowsza stabilna linia to 3.5.x, wydana w maju 2025, a 4.0 pojawiło się w listopadzie 2025. Dokładny numer patcha zmienia się co kilka tygodni, więc najpewniejszym źródłem jest plik maven-metadata.xml w Maven Central albo strona start.spring.io. Zajrzyj tam, zanim wpiszesz numer w plik builda.

Jak sprawdzić wersję Spring Boot w projekcie Maven?

Otwórz pom.xml i znajdź sekcję <parent> - tam stoi wersja, jeśli używasz spring-boot-starter-parent. Bez parentu sprawdź właściwość <spring-boot.version> albo sekcję dependencyManagement. Z terminala wywołasz mvn help:evaluate -Dexpression=project.parent.version -q -DforceStdout i dostaniesz numer bez otwierania pliku.

Czy Spring Boot 3.5 to wersja LTS?

Spring Boot nie używa oznaczenia LTS w nazwach wydań. Każda linia minor dostaje 12 miesięcy wsparcia OSS, więc 3.5.x jest wspierane do połowy 2026. Dłuższe wsparcie kupisz w pakiecie komercyjnym. Daty sprawdzasz na endoflife.date oraz na stronie projektu w sekcji support.

Kiedy wyjdzie Spring Boot 4?

Spring Boot 4.0 ukazał się w listopadzie 2025 i opiera się na Spring Framework 7. Kolejne linie wychodzą mniej więcej co pół roku, więc następnego wydania minor spodziewaj się wiosną 2026. Daty potwierdzasz w planie wydań na GitHubie projektu, bo przesuwają się przy dużych zmianach w ekosystemie.

Jak zaktualizować Spring Boot w pom.xml?

Podmień numer w sekcji <parent> na docelową wersję i uruchom mvn clean verify. Jeśli używasz właściwości <spring-boot.version>, zmień ją w jednym miejscu. Potem przejrzyj logi pod kątem ostrzeżeń o wycofanych kluczach konfiguracji i dodaj na chwilę spring-boot-properties-migrator, jeśli migrujesz przez kilka linii.

Czy warto używać wersji SNAPSHOT?

Do produkcji nie. SNAPSHOT zmienia się przy każdym buildzie, więc dwa wdrożenia z tym samym numerem mogą zawierać inny kod. To utrudnia odtworzenie błędu i psuje cache'owanie zależności. Snapshoty mają sens na bocznym branchu, gdy chcesz sprawdzić poprawkę, której jeszcze nie ma w wydaniu stabilnym.