Załóżmy, że określono numer wersji części n, np. 1.3(2 części) lub
3.5.6.2(4 części) jako ograniczenie. Następnie, aby spełnić ograniczenie, numer wersji musi spełniać oba poniższe warunki
Pierwsze n-1 części numeru wersji musi być identyczne z pierwszymi n-1 częściami ograniczenia (np. 1.xLub 3.5.6.xpasuje, ale 0.xlub 3.5.7.xnie) i
Ostatnia część numeru wersji musi być większa lub równa ostatniej części przymusu (np 1.9999i 3.5.6.2meczu, ale 1.2czy 3.5.6.1nie).
Innymi słowy
~> x 1 .x 2 .x 3 . … .X n-2 .x n-1 .x n
mecze
x 1 .x 2 .x 3 . … .X n-2 .x n-1 .y, y> = x n
Powodem, dla którego nazywa się to ograniczeniem „pesymistycznym”, a także przypadkiem jego użycia, jest to, że kiedy po prostu mówisz > x.y.z, jesteś optymistą: zakładasz, że od teraz, aż do wieczności, API nigdy się nie zmieni. To oczywiście dość odważne założenie. Jednak większość projektów mają zasady dotyczące gdy są one dopuszczone do
złamać kompatybilność wsteczną , i jak trzeba zmienić swój numer wersji, kiedy zrobić wsteczną kompatybilność złamać. Możesz zakodować te reguły numeracji wersji używając pesymistycznego ograniczenia, dzięki czemu masz pewność, że Twój kod zawsze będzie działał (zakładając, że autor innego projektu faktycznie przestrzega własnych reguł, co niestety nie zawsze ma miejsce ).
Innymi słowy: ~> oznacza, że zezwoli tylko na tę konkretną wersję i nowsze wersje podrzędne w ostatnim miejscu po przecinku.
Magne,
18
Innymi słowy, możesz użyć tego symbolu, aby aktualizować swój klejnot za pomocą wszystkich drobnych aktualizacji i uniknąć dokonywania poważnych aktualizacji, które mogą zepsuć Twoją aplikację.
Na przykład "~> 1.2" zaktualizuje twój gem do 1.3 (jeśli taka wersja jest wydana), ale nie zaktualizuje jej do 2.0
Specyfikator ~> ma specjalne znaczenie, najlepiej pokazane na przykładzie. ~> 2.0.3 jest identyczne z> = 2.0.3 i <2.1. ~> 2.1 jest identyczne z> = 2.1 i <3.0. ~> 2.2.beta będzie pasować do wersji wstępnej, takich jak 2.2.beta.12.
Obawiam się, że nie. Cieszę się, że zaakceptowana odpowiedź wyjaśnia to bardziej szczegółowo. To wyjaśnienie oparte na przykładach tak naprawdę nie pomaga mi zrozumieć, co ma na myśli operator.
tripleee
-1
Pasuje do dowolnej wersji, która ma tę samą główną / pomocniczą część. Oznacza to, że w tym przypadku haml ~> 2.2.8 będzie pasować do dowolnej wersji 2.2.x.
Można to wykorzystać, aby upewnić się, że przełomowa zmiana interfejsu API w nowym klejnocie nie spowoduje uzależnienia od tego nowo, ale zmienionego klejnotu, który w tym przypadku złamałby Hannę.
Nie jest to błędne, ale jest niekompletne. Ważne jest, aby podkreślić różnicę między ~> 2.0i ~> 2.0.0- poprzednimi dopasowaniami 2.0, 2.1, 2.2.7 i wszystkimi innymi do (ale nie włącznie) 3.0. To ostatnie pasuje do 2.0, 2.0.1, 2.0.999 i wszystkiego innego do (ale nie włącznie) 2.1.
James A. Rosen,
5
@James A. Rosen: Ponadto, nie~> 2.2.8 będzie pasować do „żadnej wersji 2.2.x”, jak twierdzi odpowiedź, ale tylko wersje 2.2.x z x ≥ 8. IOW: odpowiedź jest w najlepszym przypadku jeszcze bardziej niekompletna, granicząca z niepoprawną i zdecydowanie zwodniczy.
Odpowiedzi:
Podręcznik RubyGems nazywa to pesymistycznym ograniczeniem wersji .
Załóżmy, że określono numer wersji części n, np.
1.3(2 części) lub3.5.6.2(4 części) jako ograniczenie. Następnie, aby spełnić ograniczenie, numer wersji musi spełniać oba poniższe warunkiPierwsze n-1 części numeru wersji musi być identyczne z pierwszymi n-1 częściami ograniczenia (np.
1.xLub3.5.6.xpasuje, ale0.xlub3.5.7.xnie) iOstatnia część numeru wersji musi być większa lub równa ostatniej części przymusu (np
1.9999i3.5.6.2meczu, ale1.2czy3.5.6.1nie).Innymi słowy
mecze
Powodem, dla którego nazywa się to ograniczeniem „pesymistycznym”, a także przypadkiem jego użycia, jest to, że kiedy po prostu mówisz
> x.y.z, jesteś optymistą: zakładasz, że od teraz, aż do wieczności, API nigdy się nie zmieni. To oczywiście dość odważne założenie. Jednak większość projektów mają zasady dotyczące gdy są one dopuszczone do złamać kompatybilność wsteczną , i jak trzeba zmienić swój numer wersji, kiedy zrobić wsteczną kompatybilność złamać. Możesz zakodować te reguły numeracji wersji używając pesymistycznego ograniczenia, dzięki czemu masz pewność, że Twój kod zawsze będzie działał (zakładając, że autor innego projektu faktycznie przestrzega własnych reguł, co niestety nie zawsze ma miejsce ).źródło
Innymi słowy, możesz użyć tego symbolu, aby aktualizować swój klejnot za pomocą wszystkich drobnych aktualizacji i uniknąć dokonywania poważnych aktualizacji, które mogą zepsuć Twoją aplikację.
Na przykład "~> 1.2" zaktualizuje twój gem do 1.3 (jeśli taka wersja jest wydana), ale nie zaktualizuje jej do 2.0
źródło
Myślę, że dokumenty bundler najlepiej podsumowują to:
źródło
Pasuje do dowolnej wersji, która ma tę samą główną / pomocniczą część. Oznacza to, że w tym przypadku haml ~> 2.2.8 będzie pasować do dowolnej wersji 2.2.x.
Można to wykorzystać, aby upewnić się, że przełomowa zmiana interfejsu API w nowym klejnocie nie spowoduje uzależnienia od tego nowo, ale zmienionego klejnotu, który w tym przypadku złamałby Hannę.
źródło
~> 2.0i~> 2.0.0- poprzednimi dopasowaniami 2.0, 2.1, 2.2.7 i wszystkimi innymi do (ale nie włącznie) 3.0. To ostatnie pasuje do 2.0, 2.0.1, 2.0.999 i wszystkiego innego do (ale nie włącznie) 2.1.~> 2.2.8będzie pasować do „żadnej wersji 2.2.x”, jak twierdzi odpowiedź, ale tylko wersje 2.2.x z x ≥ 8. IOW: odpowiedź jest w najlepszym przypadku jeszcze bardziej niekompletna, granicząca z niepoprawną i zdecydowanie zwodniczy.