시맨틱 버전 파서 및 비교기

시맨틱 버전 파서란?#

시맨틱 버전(SemVer)은 대부분의 라이브러리가 릴리스에 담긴 변경의 종류를 알리는 데 쓰는 major.minor.patch 관례입니다. 버그 수정은 patch를, 하위 호환되는 추가는 minor를, 호환성을 깨는 변경은 major를 올립니다. 사전 릴리스 태그(1.0.0-beta.1)나 빌드 메타데이터(+exp.sha.1)를 더하면 semver.org 2.0.0에 정의된 전체 문법이 됩니다.

문제는 “두 버전을 비교”와 “이 버전이 내 의존성 범위를 만족하는가”를 눈으로 짚어내기 쉽게 틀린다는 것입니다. 1.0.0이 1.0.0-beta보다 높은가 낮은가? (높습니다 — 릴리스는 항상 사전 릴리스를 앞섭니다.) 1.2.3은 ^1.2.0을 만족하나요? (네.) ~1.2.0은요? (그것도 네, 하지만 더 타이트한 이유로.) 이 페이지는 사양이 정의하는 대로 버전을 파싱하고, 구성요소를 보여 주고, 선후위로 두 버전을 비교하며, package.json이 쓰는 것과 같은 ^ / ~ / >= / || / 하이픈 문법으로 범위 질의에 답합니다 — 전부 로컬에서, 추측이 아니라 실제 규칙에 대해.

사용 방법#

1. 상단의 예시 버튼으로 흔한 예시를 떨어뜨리거나, 직접 입력합니다.
2. 두 입력에 버전 A 와 버전 B 를 입력합니다. 선행 v 또는 =은 받아들여 벗겨내며, 1.2.3-beta.1+build.42는 부분까지 파싱됩니다.
3. 만족 점검을 원하면 범위 식을 입력합니다. 기본값은 ^1.2.0 || >=2.0.0 <3.0.0 — 실제 의존성 범위가 쓰이는 방식인, OR로 묶인 두 집합. 지원 문법: ^(캐럿), ~(틸드), >= <= > < =, x / X / * 와일드카드, 부분 버전(1.2), - 하이픈 범위, 그리고 집합을 OR하는 ||.
4. 두 파스 카드 를 읽습니다. 각각은 정규 clean 형태와 분해된 주, 부, 수정, 사전 릴리스, 빌드 필드를 보여 줍니다. 유효하지 않은 버전은 메시지와 함께 카드가 빨개집니다.
5. 비교 카드 를 읽습니다. 선후위에 따라 A < B, A = B, 또는 A > B를 펼치고, 더해 diff — 변경된 가장 높은 구성요소(주, 부, 수정, 사전 릴리스, 또는 빌드)를 보여 줍니다.
6. 범위 검사 카드 를 읽습니다. 입력한 범위에 대해 A가 만족하는지, B가 만족하는지 알려 줍니다.

주요 기능#

• 사양에 따른 선후위. 비교는 major.minor.patch를 걷고 이어 사전 릴리스 식별자를 걷습니다. 사전 릴리스가 없는 버전이 있는 것을 항상 앞서는 규칙과 함께. 숫자 식별자는 숫자로 비교(beta.2 < beta.11), 영숫자는 어휘적으로 비교, 숫자는 항상 영숫자 아래. 빌드 메타데이터는 파싱되어 표시되지만 선후위에 영향을 주지 않습니다.
• 캐럿과 틸드, 올바르게 디슈거. ^1.2.3은 >=1.2.3 <2.0.0; ^0.2.3은 >=0.2.3 <0.3.0; ^0.0.3은 >=0.0.3 <0.0.4 — 캐럿의 “왼쪽 가장 큰 0이 아닌” 규칙. 틸드는 같은 부에 고정: ~1.2.3은 >=1.2.3 <1.3.0.
• ||, 하이픈, 와일드카드가 있는 범위. ^1.0.0 || >=2.0.0 <3.0.0(두 집합의 OR), 1.2.0 - 1.5.0(포함 하이픈 범위), 1.x / 1.2.*(와일드카드 범위)가 모두 파싱·테스트됩니다.
• 사전 릴리스 포함 게이트. 사전 릴리스 버전은 같은 집합의 어떤 비교자가 같은 major.minor.patch에 사전 릴리스 태그를 실을 때만 범위를 만족할 수 있습니다. 그래서 1.5.0-rc.1은 ^1.2.0을 만족하지 않지만 ^1.5.0-rc.0은 만족합니다. 실제 패키지 매니저가 무작위 사전 릴리스를 릴리스 빌드에서 빼내는 방식과 일치.
• 이야기를 말하는 diff. diff 필드는 변경된 가장 높은 구성요소를 보고합니다. 그래서 1.2.3에서 2.0.0으로의 도약은 주를 보여주고, 1.0.0에서 빌드가 바뀐 1.0.0은 선후위가 바뀌지 않았어도 빌드를 보여 줍니다.
• 관대한 입력. 선행 v, 선행 =, 주변 공백이 허용되어 git 태그나 변경로그에서 복사한 버전이 수동 정리 없이 파싱됩니다.

사용 예#

기본값 — A 1.2.3, B 2.0.0, 범위 ^1.2.0 || >=2.0.0 <3.0.0 — 에서 페이지는 다음을 보고합니다.

A clean    1.2.3        (major 1, minor 2, patch 3)
B clean    2.0.0        (major 2, minor 0, patch 0)
compare    1.2.3  <  2.0.0
diff       major
range      A satisfies   B satisfies

두 버전 모두 범위를 만족하지만, 다른 이유로: A는 첫 번째 OR 집합(^1.2.0 → >=1.2.0 <2.0.0)에, B는 두 번째(>=2.0.0 <3.0.0)에 들어갑니다. B를 3.0.0으로 바꾸면 배지가 만족하지 않음으로 뒤집힙니다 — 상한 <3.0.0이 그것을 배제하기 때문입니다.

사전 릴리스 규칙을 보려면 A를 1.5.0-rc.1, B를 1.5.0으로 설정하고 범위를 ^1.5.0-rc.0으로 유지합니다. 이제 A는 만족(같은 1.5.0, 범위가 일치하는 사전 릴리스 태그를 실음)하지만, 평범한 ^1.5.0은 1.5.0-rc.1을 통과시키지 않을 것입니다 — 그 게이트가 정확히 옵트인하기 전까지 릴리스 후보를 릴리스 의존성 해석에서 빼두기 위해 존재합니다.

FAQ#

1.0.0이 1.0.0-beta보다 높나요?#

네. 사전 릴리스 태그가 없는 버전은 같은 major.minor.patch에서 사전 릴리스 태그가 있는 것보다 항상 선후위가 높습니다. 그래서 1.0.0 > 1.0.0-rc.1 > 1.0.0-beta.11 > 1.0.0-alpha. 릴리스가 “골드”가 되는 것이 레이블 변경이 아니라 실제 선후위 상승인 이유입니다.

^와 ~의 차이는?#

캐럿은 가장 왼쪽의 0이 아닌 구성요소를 수정하지 않는 업데이트를 허용합니다. ^1.2.3은 1.2.3에서 2.0.0(미포함)까지의 어떤 1.x.x를 허용합니다. 틸드는 더 엄격합니다. 전체 버전이 주어지면 부를 고정합니다. ~1.2.3은 1.2.x만 허용합니다. 주(~1)만 주어지면 틸드와 캐럿 모두 전체 주 범위를 허용합니다. 대부분의 라이브러리는 ^로 고정하고, 직접 게시한 패키지의 패치는 종종 ~를 씁니다.

왜 내 사전 릴리스 버전이 ^1.0.0을 만족하지 않나요?#

설계된 동작입니다. 1.5.0-rc.1 같은 사전 릴리스는 같은 AND 집합의 어떤 비교자가 같은 1.5.0에 사전 릴리스 태그를 실 때만 범위를 만족합니다. ^1.0.0은 1.5.0에 사전 릴리스 없이 >=1.0.0 <2.0.0-0으로 디슈거되어, 게이트가 릴리스 빌드가 누군가의 무작위 릴리스 후보를 끌어오지 않게 합니다. 옵트인하려면 ^1.5.0-rc.0이라고 명시하세요.

빌드 메타데이터가 비교에 영향을 주나요?#

아닙니다. 1.0.0+exp.sha.5와 1.0.0+exp.sha.6은 선후위가 같습니다 — 빌드 메타데이터는 식별 전용입니다. 파서는 여전히 그것을 보여 주고(diff는 메타데이터만 다를 때 빌드 변경을 보고), 결코 순서를 결정하지 않습니다.