Jaki jest najnowszy Spring Boot i które wydanie wybrać do nowego projektu

Na pytanie, jaki jest najnowszy Spring Boot, odpowiadam krótko: najnowszym stabilnym wydaniem jest Spring Boot 3.5.x z maja 2025 roku, a linię 4.0 opartą na Spring Framework 7 zapowiedziano na listopad 2025. Do nowego projektu najczęściej bierz 3.5.x - chyba że startujesz na Javie 21 i chcesz od razu celować w nowszą linię.

Jaki jest najnowszy Spring Boot i jak czytać numery wersji

Numer wersji Spring Boota ma trzy człony: MAJOR.MINOR.PATCH. Zapis 3.5.2 oznacza trzecią linię, piąte wydanie minor w tej linii i drugą łatkę w nim. Gdy widzisz dopisek M3 albo RC1, patrzysz na milestone albo kandydata do wydania. Takich wersji nie wrzucasz na produkcję, bo API może się jeszcze zmienić między wydaniami.

Nowe wersje minor wychodzą u Springa mniej więcej co pół roku. Łatki pojawiają się co miesiąc, zwykle w trzeci czwartek. Dzięki temu łatwo zaplanować podnoszenie wersji: raz na kwartał robisz przegląd i wchodzisz na najświeższą łatkę, a decyzję o zmianie linii podejmujesz raz, przy starcie projektu albo przy większym refaktorze.

Linia 3.x kończy się na wydaniu 3.5. To ostatnie minor w tej gałęzi i zarazem najbezpieczniejszy wybór, jeśli zależy ci na zgodności z bibliotekami, które nie zdążyły wydać wersji pod Spring Framework 7. Kolejne zmiany idą już do 4.0. Jeśli potrzebujesz szerszego tła, Spring Boot co to jest i dlaczego pomaga oddzielić sam framework od projektu startowego.

Kiedy pytasz, jaki jest najnowszy Spring Boot, doprecyzuj, co masz na myśli. Najnowsza łatka w stabilnej linii to jedno, najnowszy milestone to drugie, a najnowszy snapshot z repozytorium Springa to trzecie. Do decyzji o projekcie liczy się tylko pierwsza kategoria. Jeśli interesuje cię najnowsza wersja Spring Boot i jak czytać numery wydań, pamiętaj o tym rozróżnieniu.

Spring Boot 3.5 kontra 4.0: różnice, które wpływają na decyzję

Spring Boot 4.0 stoi na Spring Framework 7. To największa zmiana w całym porównaniu, bo pociąga za sobą resztę. Framework 7 porządkuje moduły, wymaga Javy 17 jako minimum i mocno przebudowuje obsługę klienta HTTP. Dostajesz też wsparcie dla wersjonowania API w adnotacjach, co przy publicznym REST API oszczędza sporo własnych obejść. Jeśli zastanawiasz się, Czym się różni Spring od Spring Boot, to właśnie tutaj ta różnica ma praktyczne skutki.

W 4.0 wchodzi Jackson 3, a to zmiana, którą odczujesz wszędzie tam, gdzie ręcznie tworzysz ObjectMapper albo podpierasz się starymi konfiguracjami serializacji. Spring Security przechodzi na kolejną generację, więc konfiguracje zabezpieczeń trzeba przejrzeć, zwłaszcza jeśli masz własne filtry i łańcuchy. Część klas oznaczonych jako przestarzałe w 3.x znika bez zamiennika jeden do jednego.

Spring Boot 3.5 to z kolei wydanie, które niczego nie wywraca. Masz tam wsparcie dla Javy 17-24, stabilne API, dopracowane testy i pełną zgodność z bibliotekami, które na co dzień pracują w polskich firmach. Jeśli używasz Spring Cloud, Hibernate, Testcontainers czy klienta do systemu księgowego, sprawdź, czy wydanie wspiera twoją linię. Spring Cloud zawsze dopasowuje swój release train do konkretnej wersji Boota i to on często wyznacza granicę, której nie przeskoczysz.

W praktyce różnica sprowadza się do pytania: chcesz przewidywalności czy chcesz nowego? 3.5 daje pierwsze, 4.0 daje drugie i wymaga kilku dni na przegląd kodu.

Jak długo dostaniesz wsparcie, czyli cykl życia wydań

Spring traktuje wsparcie otwartoźródłowe jako okno, nie jako obietnicę na lata. Każde wydanie minor dostaje około 12 miesięcy darmowych poprawek bezpieczeństwa i błędów. Potem możesz albo przejść na nowszą linię, albo wykupić wsparcie komercyjne.

Wydanie 3.5 jest wyjątkiem, bo zamyka całą linię 3.x. Spring wydłużył dla niego okres wsparcia open source i według opublikowanego harmonogramu łatki mają wychodzić co najmniej do połowy 2026 roku, a dalej przez kanał komercyjny. To daje ci realny czas na przygotowanie migracji do 4.0 bez presji.

Dlaczego to ma znaczenie przy wyborze wersji? Bo praca na wydaniu bez wsparcia oznacza, że zgłoszony błąd bezpieczeństwa zostaje bez łatki. Przy audycie bezpieczeństwa albo przy pytaniach od klienta korporacyjnego taki stan jest trudny do obrony. Znam zespoły, które siedzą na Spring Boot 2.7 i tłumaczą się „bo działa”. Działa do pierwszego CVE.

Plan minimum wygląda tak: raz w miesiącu podnosisz łatkę w swojej linii, raz na pół roku sprawdzasz harmonogram wsparcia i zapisujesz w backlogu zadanie na migrację, zanim termin się zbliży.

Od czego zależy wybór wersji: Java, biblioteki i środowisko

Zacznij od Javy, bo ona ustala podłogę. Spring Boot 3.x i 4.x wymagają minimum Javy 17. Jeśli możesz wybrać, weź Javę 21 - to LTS z wątkami wirtualnymi, które przy aplikacji mocno obciążonej wejściem i wyjściem potrafią zmienić charakterystykę wydajności bez przepisywania kodu. Przy okazji warto znać Kiedy używać record w Java 17, bo nowsze konstrukcje języka ułatwiają porządkowanie modelu domenowego.

Drugi filtr to biblioteki firm trzecich. Wypisz te, bez których projekt nie ruszy, i sprawdź ich deklaracje zgodności. Klient do płatności, biblioteka do faktur, sterownik do bazy, integracja z KSeF albo z Allegro REST API - każda z nich może trzymać cię na 3.x jeszcze przez kilka miesięcy.

Trzeci filtr to środowisko uruchomieniowe. Jeśli budujesz obraz natywny z GraalVM, wersja frameworka wpływa na to, które adnotacje i konfiguracje są obsługiwane w czasie kompilacji. Podobnie przy wdrożeniach na Kubernetesie: nowsze wydanie zwykle lepiej współpracuje z aktualnymi obrazami bazowymi i metrykami Actuatora.

Na koniec zespół. Jeśli w firmie nikt nie pracował jeszcze ze Spring Framework 7, wejście na 4.0 w nowym projekcie oznacza naukę równolegle z dostarczaniem funkcji. Czasem to dobry moment, żeby to zrobić, bo nowy projekt ma najmniej długu technicznego. Czasem lepiej najpierw ustabilizować produkt na 3.5, a migrację zaplanować na spokojniejszy kwartał.

Nowy projekt krok po kroku: Initializr, Maven i Gradle

Generowanie projektu zaczynasz na start.spring.io. Wybierz Maven albo Gradle, język Java, wersję Boota i poziom Javy, a potem dorzuć zależności. Na start wystarczą web, data-jpa, validation i actuator. Reszta dokłada się później, kiedy pojawia się realna potrzeba.

Ten sam efekt osiągniesz z terminala, co przydaje się przy automatyzacji:

curl https://start.spring.io/starter.zip \
  -d type=maven-project \
  -d language=java \
  -d bootVersion=3.5.0 \
  -d javaVersion=21 \
  -d dependencies=web,data-jpa,validation,actuator \
  -o demo.zip

Po rozpakowaniu trzymaj się kilku zasad. Nie przypinaj wersji bibliotek Springa ręcznie - użyj spring-boot-starter-parent albo zaimportuj BOM, żeby wersje były spójne. Korzystaj z wrappera mvnw albo gradlew, bo wtedy build działa tak samo na twoim laptopie i na serwerze CI. Włącz Docker Compose support, jeśli lokalnie stawiasz bazę i Kafkę, bo Spring sam podniesie kontenery przy starcie aplikacji.

Zanim napiszesz pierwszą funkcję, dodaj Testcontainers i jeden test integracyjny, który sprawdza, że kontekst się podnosi, a migracje bazy przechodzą. Taki test kosztuje kilkanaście minut pracy, a ratuje przy każdej zmianie wersji.

Wersję zapisz jawnie w pliku konfiguracyjnym builda, nie w głowie. Kiedy za pół roku ktoś zapyta, na czym stoi projekt, odpowiedź ma być w repozytorium, a nie w czyjejś pamięci.

Co z projektami na Spring Boot 2.x i migracją na nowszą linię

Jeśli twój projekt stoi na 2.x, największym wyzwaniem nie jest sam Boot, a przejście z Java EE na Jakarta EE. Pakiety z javax.* zmieniają się na jakarta.*, a to dotyka encji JPA, walidacji i filtrów serwletowych. Do tego dochodzi Java 17 jako minimum i nowa generacja Spring Security.

Kolejność ma znaczenie. Najpierw podnieś projekt do ostatniej łatki 2.7, potem przejdź na 3.0, a dopiero stąd idź wyżej. Przeskok z 2.x od razu na 4.0 to proszenie się o tygodnie debugowania, bo nakładają się dwie duże zmiany.

Z narzędzi przydają się trzy rzeczy: spring-boot-properties-migrator, który wypisze Ci nieaktualne klucze konfiguracji, recepty OpenRewrite do automatycznej zamiany importów i pakietów oraz porządny zestaw testów integracyjnych. Bez testów migracja zamienia się w zgadywanie, czy błąd wyszedł z twojego kodu, czy z podniesionej zależności. Uruchom build z flagą --debug i przeczytaj raport autokonfiguracji, bo tam najszybciej zobaczysz, co przestało działać.

Najczęstsze pytania

Jaki jest najnowszy Spring Boot?

Najnowszym stabilnym wydaniem jest Spring Boot 3.5.x, którego premiera odbyła się w maju 2025 roku, a kolejne łatki wychodzą co miesiąc. Równolegle trwają prace nad linią 4.0 opartą na Spring Framework 7, zapowiedzianą na listopad 2025. Jeśli szukasz wersji do produkcji dzisiaj, sięgnij po najświeższą łatkę z linii 3.5.

Czy Spring Boot 4 jest już dostępny?

Wydanie 4.0 jest zaplanowane na listopad 2025 roku i do tego czasu dostępne są tylko wersje milestonowe oraz kandydaci do wydania. Możesz ich używać do testów i nauki, ale nie do projektów, które mają trafić na produkcję. Poczekaj na wydanie GA i na to, żeby najważniejsze biblioteki zdążyły wydać zgodne wersje.

Jaka wersja Javy jest wymagana w Spring Boot 3.5?

Spring Boot 3.5 wymaga minimum Javy 17, ale obsługuje też nowsze wersje, w tym Javę 21 i 24. Do nowego projektu polecam Javę 21, bo to wydanie LTS z wątkami wirtualnymi i długim okresem wsparcia. Java 17 nadal działa poprawnie, jeśli twoja infrastruktura nie pozwala na szybszą aktualizację.

Które wydanie Spring Boot wybrać do nowego projektu?

W większości przypadków bierz Spring Boot 3.5 w najnowszej łatce i Javę 21. To połączenie stabilne, dobrze udokumentowane i zgodne z bibliotekami, które są już na rynku. Linię 4.0 wybierz wtedy, gdy startujesz po jej premierze, zespół ma czas na naukę, a twoje zależności mają wydania pod Spring Framework 7.

Jak sprawdzić wersję Spring Boot w projekcie?

Otwórz plik pom.xml lub build.gradle i znajdź wpis spring-boot-starter-parent albo spring-boot-dependencies. Tam zapisana jest wersja. Drugi sposób to uruchomienie aplikacji i spojrzenie w log startowy, gdzie Spring wypisuje swoją wersję. Trzeci to endpoint Actuatora /actuator/info, jeśli masz go włączonego.

Czy Spring Boot 2.7 jest jeszcze wspierany?

Nie, wsparcie otwartoźródłowe dla linii 2.x zakończyło się w listopadzie 2023 roku. To oznacza, że nowe luki bezpieczeństwa nie dostają już darmowych poprawek. Jeśli nadal utrzymujesz projekt na 2.7, zaplanuj migrację przez 3.0 do 3.5. Największa praca czeka cię przy przejściu z javax na jakarta.