2015-03-26 11 views
5

Po wprowadzeniu Spring IO platform zarządzamy naszymi zależnościami projektu przy użyciu platformy Spring IO platform-bom. Dlatego nie określamy już dedykowanych wersji dla pojedynczych komponentów Spring (lub nawet bibliotek platformy) (i jesteśmy ostrożni, jeśli chodzi o ich zastępowanie).Wiosenne zarządzanie wersjami platformy IO

Wadą tego rozwiązania jest to, że nie możemy używać nowych wersji pojedynczych komponentów zgodnie z zaleceniami, np. (wczoraj) announced nowa wersja 4.1.6 Spring Framework, dopóki nie zostanie zintegrowana z nową wersją platformy Spring IO.

Byłoby miło dowiedzieć się więcej o zarządzaniu wydaniami platformy Spring IO. Czy istnieje ogólny plan na wydanie nowej wersji? Pomyślałem, że w rzeczywistości nowa wersja Spring Framework wywołałaby nową wersję Spring IO, ale to nie wydaje się być (nie było nowej wersji z Spring Framework 4.1.5 i przypuszczam, że następna wersja będzie zawierać Spring Framework 4.1.6).

Wszelkie wgląd w zarządzanie wydaniami na platformie Spring IO byłby dla mnie interesujący i pomocny.

+0

Czy próbowałeś przesłonić właściwość 'spring.framework.version'? – chrylis

+0

Nadpisywanie @chrylis prawdopodobnie by działało, ale mogłoby w jakiś sposób zaszkodzić integralności dobrze dopasowanych wersji modułów w platformie-bom - tak nie jest to, co chciałbym robić. – FrVaBe

+0

Nie, jeśli przeważasz tylko w niewielkich wersjach, które są poprawkami. – chrylis

Odpowiedz

7

Ogólna zasada polega na tym, że co 6-8 tygodni wydajemy nową wersję platformy. Nie jest to przesądzone, ponieważ będą okazje do częstszych wydań; na przykład w celu wyeliminowania luki w zabezpieczeniach.

Jak być może już wiesz, Platforma opiera się na Spring Boot. Rozciąga bomby Spring Boot, dodając zarządzanie zależnościami dla wielu innych wiosennych projektów i ich zależności. Ogólnie mówiąc, po wydaniu nowej wersji Spring Boot uruchamia się wydanie nowej wersji platformy. Ponadto nowa wersja Spring Framework często wyzwala wydanie nowej wersji Spring Boot.

Jak zauważyłeś, Spring Framework 4.1.5 i Spring Boot 1.2.2 były wyjątkiem od tej reguły. Podczas gdy Spring Boot 1.2.2 został wydany wkrótce po Spring Framework 4.1.5, nie ma wersji platformy zawierającej te dwa wydania. Powodem tego jest fakt, że w Spring Boot 1.2.2 było kilka błędów związanych z Spring Security, które chcemy pomóc użytkownikom platformy uniknąć. Aby to osiągnąć, postanowiliśmy odroczyć wydanie Platformy 1.1.2, dopóki Spring Boot 1.2.3 nie będzie dostępny, a problemy Spring Security zostały rozwiązane. Pomiędzy znajdowaniem się w czołówce i ochroną przed błędami istnieje niewielki kompromis.

Należy rozważyć platforma jako zalecanej zestaw wersji w użyciu, ale to na pewno nie jest tylko zestaw wersjach, które można wykorzystać. Wykorzystanie właściwości wersji w bombie platformy jest celowe i ułatwia użytkownikom nadpisywanie wersji w celu spełnienia ich potrzeb. Przewody różnych projektów wiosennych bardzo poważnie podchodzą do kompatybilności wstecznej i zawsze powinieneś mieć możliwość uaktualnienia do nowszej wersji obsługi technicznej dowolnego projektu bez żadnych trudności. W wielu przypadkach można również uaktualnić do nowej wersji drugorzędnej, ale należy zachować ostrożność.

+0

Dzięki za szybkie informacje z pierwszej ręki. – FrVaBe

+0

Czy naprawdę masz na myśli "mniejszą" wersję w swoim ostatnim zdaniu? – FrVaBe

+0

Ja. W _many_ przypadkach przejście z wersji 1.0.x do 1.1.x projektu przebiegnie bezproblemowo, ale może zająć trochę pracy. Nie stosujemy dogmatycznego podejścia do semantycznego wersjonowania, więc warto sprawdzić informacje o wydaniu projektu po przyjęciu nowej mniejszej (lub głównej wersji). Pobranie nowej wersji obsługi (przejście z wersji 1.0.x na 1.0.y) powinno zawsze przebiegać bez problemu. Jeśli tak nie jest, prawie na pewno znalazłeś błąd. –

Powiązane problemy