Spring Boot latest stable version - jak dobrać wersję do projektu produkcyjnego

Spring Boot latest stable version to obecnie linia 3.5.x, a o wyborze wersji do produkcji decyduje nie sam numer, tylko wsparcie. Musisz spełnić dwa warunki: linia ma być w okresie darmowego wsparcia OSS, a projekt ma działać na Javie 17 lub nowszej. Wybierasz najnowszą wersję z aktywnie wspieranej linii, nie najwyższy numer, jaki znajdziesz w internecie.

Spring Boot latest stable version, czyli jak sprawdzić, co jest wydane dzisiaj

Spring publikuje nową linię minor mniej więcej co pół roku, w maju i listopadzie, a poprawki patch co kilka tygodni. Wersja, którą widziałeś na blogu rok temu, prawdopodobnie nie jest już aktualna. Zamiast zgadywać, zajrzyj do trzech miejsc.

Pierwsze to strona projektu, spring.io/projects/spring-boot, a konkretnie tabela wsparcia. Znajdziesz tam aktualnie wspierane linie i daty ich końca. Drugie to GitHub, repozytorium spring-projects/spring-boot i zakładka Releases. Tam widać dokładnie, kiedy wyszedł ostatni patch i co zawiera. Trzecie to start.spring.io, gdzie generator od razu zaproponuje Ci aktualną wersję przy tworzeniu nowego projektu.

Jeśli wolisz sprawdzić wersję z terminala, wystarczy jedno polecenie, ale wcześniej warto ogarnąć, jak działa Spring Boot current version jak śledzić aktualną:

curl -s https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-parent/maven-metadata.xml | grep -E "latest|release"

W projektach z Mavenem dorzuć plugin versions-maven-plugin i uruchom mvn versions:display-dependency-updates. W Gradle działa dependencyUpdates z pluginu Ben Manes. Oba pokażą, o ile wydań zostałeś z tyłu.

Uwaga na pułapkę z metadanymi Maven. Pole latest potrafi wskazać wydanie RC, bo repozytorium nie odróżnia kandydata do wydania od wersji finalnej. Do produkcji wchodzi wyłącznie numer bez przyrostka -M1, -RC1 czy -SNAPSHOT. Liczy się też ostatni patch: 3.5.7 jest lepszy niż 3.5.0, bo zbiera poprawki bezpieczeństwa i błędy znalezione po premierze linii.

Czy Spring Boot ma LTS i jak działa wsparcie wersji

Krótka odpowiedź: nie ma czegoś takiego jak oficjalny LTS Spring Boot, choć to słowo wraca w dyskusjach. Zespół Springa stosuje inny model. Każda linia minor dostaje około 13 miesięcy darmowego wsparcia OSS, w którym wydawane są poprawki błędów i łaty bezpieczeństwa. Potem możesz przedłużyć wsparcie komercyjnie w ramach Tanzu Spring.

Z tego wynikają konkretne daty. Linia 3.5, wydana w maju 2025, ma wsparcie OSS zaplanowane do czerwca 2026. Linia 3.4 kończy je na przełomie 2025 i 2026 roku. Linia 3.3 wyszła z darmowego wsparcia w połowie 2025. Daty sprawdzaj na stronie wsparcia projektu, bo to jedyne wiarygodne źródło. To jedyne wiarygodne źródło, jeśli chcesz ustalić najnowszą wersję Spring Boot i jej horyzont wsparcia. Jeśli wpiszesz w Google spring boot latest stable version, dostaniesz mieszankę wyników, od dokumentacji po wpisy sprzed dwóch lat.

Co to oznacza dla Ciebie? Gdy kończy się wsparcie OSS Twojej linii, przestajesz dostawać darmowe łaty bezpieczeństwa. Masz wtedy trzy wyjścia: migrujesz na nowszą linię, kupujesz wsparcie komercyjne albo świadomie akceptujesz ryzyko. Trzecia opcja bywa kosztowna, zwłaszcza gdy w grę wchodzi audyt bezpieczeństwa albo klauzula w umowie z klientem korporacyjnym.

Wyjątkiem od reguły była linia 2.7, której komercyjne wsparcie rozciągnięto na wiele lat, bo sporo firm nie zdążyło przejść z javax. na jakarta.. To pokazuje, że przy dużych zmianach API cykl życia linii może wyglądać inaczej niż zwykle.

Java, Spring Framework i biblioteki zewnętrzne: co sprawdzić przed podniesieniem wersji

Sama wersja Spring Boot to dopiero początek. Musisz sprawdzić cały łańcuch zależności, bo niezgodność na tym poziomie psuje build albo, gorzej, wywala aplikację dopiero na produkcji. Jeśli chcesz uporządkować podstawy, zobacz, Czym się różni Spring od Spring Boot.

Java. Spring Boot 3.x wymaga minimum Javy 17, a linia 3.5 obsługuje Javę do wersji 24. W produkcji najrozsądniejszy wybór to Java 21, czyli wydanie z długoterminowym wsparciem producenta. Kompiluj z flagą --release 21, żeby nie użyć przypadkiem API, którego nie ma w środowisku uruchomieniowym.

Spring Framework i Jakarta EE. Boot 3.x stoi na Spring Frameworku 6 i Jakarta EE 10. Boot 4.0 przechodzi na Spring Framework 7 i Jakarta EE 11, a razem z nim zmienia się część pakietów i domyślny serializator JSON. Jeśli masz w kodzie importy javax.servlet, migracja i tak Cię czeka. Nie da się jej odkładać w nieskończoność.

Spring Cloud. Każdy release train jest przypisany do konkretnej linii Boot. Wzięcie najnowszego Spring Cloud i najstarszego wspieranego Boota to przepis na wyjątek przy starcie kontekstu aplikacji. Sprawdź tabelę kompatybilności w dokumentacji projektu, zamiast liczyć na szczęście.

Biblioteki firm trzecich. Sterowniki baz danych, klienty Kafki, biblioteki do płatności czy integracji z systemami ERP mają własne cykle wydań. Zanim podniesiesz Boota, przejrzyj ich changelogi pod kątem wspieranych wersji Spring Frameworka.

Konflikty wyłapiesz poleceniem mvn dependency:tree albo ./gradlew dependencies. Rodzic spring-boot-starter-parent i BOM spring-boot-dependencies zarządzają wersjami kilkuset bibliotek, więc nie nadpisuj ich bez powodu. Ręczne przypięcie wersji Jacksona czy Hibernate'a to najczęstsza przyczyna problemów po aktualizacji.

Nowy projekt czy istniejący system? Kiedy aktualizować, a kiedy poczekać

Decyzja zależy od tego, na jakim etapie jest projekt, a nie od tego, co wypada zrobić.

Nowy projekt produkcyjny. Bierz najnowszą stabilną linię z ostatnim patchem. Nie ma powodu startować na wersji, której wsparcie kończy się za rok. Wygeneruj szkielet na start.spring.io i od razu zapisz w README numer wersji oraz datę końca wsparcia. Jeśli budujesz pierwszy endpoint, zobacz, jak napisać prosty REST API w Spring.

Istniejący system, który ma testy i działa. Aktualizuj regularnie, małymi krokami. Jedna linia minor na kwartał to mniej pracy niż przeskok o trzy linie po dwóch latach.

Istniejący system bez testów. Najpierw pokryj testami krytyczne ścieżki, potem aktualizuj. Migracja na ślepo w systemie, którego nikt do końca nie rozumie, kończy się tygodniami debugowania.

System pod audytem. Regulacje i umowy z klientami coraz częściej wymagają, żeby w produkcji nie było znanych podatności o wysokiej wadze. Argument „działa, nie ruszamy” przestaje działać, gdy pojawia się CVE w bibliotece, której nikt nie chce aktualizować.

Sezon. Jeśli prowadzisz e-commerce i przed Tobą Black Friday, nie wdrażaj nowej wersji frameworka na dwa tygodnie przed szczytem. Zaplanuj migrację na spokojniejszy okres, nawet jeśli oznacza to kilka miesięcy opóźnienia.

Praktyczna reguła: gdy do końca darmowego wsparcia Twojej linii zostaje mniej niż sześć miesięcy, zaczynasz planować migrację. Nie czekasz na moment, w którym przestaniesz dostawać łaty bezpieczeństwa, bo wtedy działasz pod presją.

Migracja na nowszą wersję Spring Boot krok po kroku

Migracja rzadko jest skomplikowana technicznie. Problemem bywa jej organizacja, więc rozbij ją na etapy.

1. Ustal wersję docelową. Sprawdź, czy wszystkie biblioteki, z których korzystasz, wspierają tę linię.
2. Zrób gałąź i uruchom pełny zestaw testów przed zmianami. Potrzebujesz punktu odniesienia.
3. Podnieś wersję w jednym commicie. W Mavenie zmieniasz wersję rodzica, w Gradle wpis w pluginie org.springframework.boot.
4. Użyj OpenRewrite. Recipe UpgradeSpringBoot podnosi numer wersji i poprawia przestarzałe API, importy oraz konfigurację. Oszczędza godziny ręcznej pracy.
5. Dodaj spring-boot-properties-migrator. Narzędzie wypisze w logach właściwości, które zmieniły nazwę albo zostały usunięte, i podpowie, czym je zastąpić. Tę zależność usuwasz przed wdrożeniem na produkcję.
6. Popraw konfigurację środowisk. Zmiany dotyczą plików application.yml, sekretów w CI, obrazów Docker z nową wersją Javy i skryptów wdrożeniowych.
7. Przejrzyj testy integracyjne. Testcontainers pozwala sprawdzić aplikację na prawdziwej bazie i brokerze wiadomości, a nie na mockach.
8. Wdróż stopniowo. Blue-green albo canary deployment pokaże problemy na małym ruchu, zanim zobaczą je wszyscy użytkownicy. Miej przygotowany rollback.

Do drobnych aktualizacji w obrębie linii wystarczy Renovate albo Dependabot. Automatyczny pull request z podbitym patchem i przechodzącymi testami to najlepszy sposób, żeby nie zostać z wersją sprzed roku.

Checklista przed wdrożeniem nowej wersji na produkcję

Zanim wypuścisz zmiany, przejdź po liście.

• Wersja nie ma przyrostka -RC, -M ani -SNAPSHOT.
• Wybrałeś najnowszy patch w obrębie linii, nie pierwszy z brzegu.
• Zależności przechodzą skan podatności (OWASP Dependency-Check, Trivy, Snyk).
• Testy jednostkowe i integracyjne są zielone na środowisku zbliżonym do produkcyjnego.
• Obraz kontenera ma aktualną wersję Javy, najlepiej 21.
• Konfiguracja nie zawiera usuniętych właściwości, a migrator został wyłączony.
• Masz metryki i logi, po których poznasz regresję w pierwszych godzinach.
• Znasz numer poprzedniej wersji i umiesz wrócić do niej w kilka minut.
• W dokumentacji projektu jest wpisana wersja i data końca jej wsparcia.

Ostatni punkt często się pomija i potem nikt nie pamięta, dlaczego projekt stoi na Boot 3.2. Jedna linijka w README oszczędza godzinę śledztwa pół roku później.

Najczęstsze pytania

Jaka jest najnowsza stabilna wersja Spring Boot?

Spring Boot latest stable version zmienia się co kilka miesięcy, więc najpewniejszym źródłem jest tabela wsparcia na spring.io/projects/spring-boot oraz zakładka Releases w repozytorium na GitHubie. W momentach przejściowych między liniami najnowszy numer bywa świeżo wydany, a mimo to nie jest jeszcze najlepszym wyborem do produkcji. Poczekaj na dwa, trzy wydania patch, zanim postawisz na nim system.

Czy Spring Boot 3.5 to wersja LTS?

Spring Boot nie używa oficjalnie określenia LTS. Każda linia minor dostaje około 13 miesięcy darmowego wsparcia OSS, a potem można je przedłużyć komercyjnie. Linia 3.5 ma wsparcie OSS zaplanowane do czerwca 2026, czyli dłużej niż typowa linia. Jeśli potrzebujesz horyzontu kilku lat bez migracji, wykup wsparcie komercyjne albo zaplanuj regularne aktualizacje.

Jaką wersję Javy wymaga najnowszy Spring Boot?

Spring Boot 3.x wymaga minimum Javy 17 i obsługuje kolejne wydania, w tym 21 i 24 w linii 3.5. Do produkcji wybierz Javę 21, bo to wydanie z długoterminowym wsparciem i najlepszym wsparciem narzędziowym. Sterowniki, agenci APM i biblioteki natywne najszybciej dostają wersje pod tę właśnie Javę.

Czy warto aktualizować Spring Boot w istniejącym projekcie produkcyjnym?

Tak, jeśli linia zbliża się do końca wsparcia OSS. Po jego zakończeniu nie dostajesz darmowych łat bezpieczeństwa, a każda nowa podatność zostaje w Twoim systemie. Jeśli projekt nie ma testów, zacznij od ich napisania. Aktualizacja o jedną linię minor na raz, z pełnym zestawem testów i wdrożeniem canary, jest znacznie tańsza niż przeskok o kilka linii pod presją.

Jak sprawdzić, czy moja wersja Spring Boot jest jeszcze wspierana?

Wejdź na stronę projektu i znajdź tabelę wsparcia. Sprawdź, czy Twoja linia minor ma status aktywnej i jaka data widnieje przy końcu wsparcia OSS. Drugim źródłem jest zakładka Releases na GitHubie - jeśli ostatnie wydania w linii mają ponad rok, wsparcie prawdopodobnie się skończyło. W Mavenie możesz też sprawdzić, czy w repozytorium pojawiają się nowe wersje patcha.

Co się stanie, gdy Spring Boot skończy wsparcie OSS?

Przestaniesz dostawać darmowe poprawki błędów i łaty bezpieczeństwa dla tej linii. Aplikacja nadal będzie działać, ale nowo wykryte podatności zostaną niezałatane. Masz wtedy trzy opcje: migracja na wspieraną linię, wykupienie wsparcia komercyjnego albo świadome zaakceptowanie ryzyka. Trzecia opcja rzadko przechodzi audyt, jeśli system przetwarza dane osobowe albo obsługuje płatności.