소프트웨어 릴리즈 버전 넘버에 대한 네이밍 시스템
버전 관리를 함에 있어서 정해진 규칙 없이 제각각의 방식으로 관리하지 않고 규칙을 정해서 관리하기 위해 제안 됨.
아래와 같은 형태를 가진다.
> "devDependencies": {
"pimatic-meross": "^0.1.1",
"react-test-renderer": "^16.13.0",
"react-zeroconfig": "^3.27.2-alpha.2"
>
- 2 (version)
3 = MAJOR
- 기존 API 변경 및 삭제 되거나 하위 호환이 되지 않는 버전
4 = MINOR
- 신규 기능이 추가되거나 개선되었고 하위 호환이 되는 버전
2 = PATCH
- 버그 수정이 되었고 하위 호환이 되는 버전
일반적인 규칙
1. 반드시 공개 API를 정의해야 하며 API는 코드 자체에 정의되어 있거나 명시적으로 문서화 되어야 한다.
2. 일반 버전 명은 반드시 X.Y.Z 형태로 나타내며 정수이고 X는 주요한 버전, Y는 작은버전, Z는 패치 버전이며 1씩 증가한다.
3. 주요버전(X)이 올라가면 작은 버전(Y)와 패치버전(Z)는 0으로 초기화 되어야하며 작은 버전(Y)이 올라가면 패치버전(Z)는 0으로 초기화 되어야 한다.
4. 주요버전 0.Y.Z는 초기개발을 위한 것
5. 버전 1.0.0을 공개 API로 정의하고 이후 버전은 변경에 따라 결정한다.
(1) 패치 버전(Z)은 하위 호환 되며 버그 수정 시 올라간다.
(2) 작은 버전(Y)는 기존 공개 API가 하위 호환되고 새로운 기능, 개선이 추가되거나 공개 API 하나 이상이 deprecated(더 이상 사용 되지 않는)가 되어도 올라가야 한다. 이 때 작은 버전이 올라가면 패치 버전은 꼭 0 이 되어야 한다.
(3) 하위 호환이 되지 않는 변화가 추가될 때 반드시 올라가야 한다. 이는 패치 수준과 작은 수준의 변화를 포함할 수 있으나, 주요 버전이 올라가면 나머지 버전은 모두 0이 되어야 한다.
6. 선행 배포 버전은 대시와 점으로 나누어진 식별자들의 묶음을 패치 버전 뒤에 표시하며 식별자들은 ASCII 영숫자와 대시만으로 구성되어야 하며 일반 버전보다 낮은 우선순위를 갖는다. ( 1.0.0-alpha < 1.0.0 )
7. 개발 버전은 더하기와 점으로 나누어진 식별자들 묶음을 패치 버전 뒤에 표시하며 일반 버전보다 높은 우선순위를 갖는다. ( 1.0.0+001 > 1.0.0 )
8. 우선 순위는 주요, 작은, 패치 선행 배포, 빌드 식별자 내 숫자 순으로 계산 선행 배포와 빌드 버전의 우선 순위는 반드시 각 점으로 나누어진 식별자들이 아래 규칙에 따라 비교되어야 한다.
(1) 숫자로만 이루어진 식별자는 숫자로 비교
(2) 문자와 대시가 포함된 식별자는 ASCII 정렬 순서대로 비교. 숫자 식별자는 숫자가 아닌 식별자보다 낮은 우선순위를 가진다.
ex) 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < 1.3.7+build 등등..
9. 배포하면 그 버전의 내용은 절대 변경해서는 안된다.🙅
Node에서 쓰는 Version Range
일반 범위
- < 명시된 버전보다 낮은 버전
- <= 명시된 버전보다 같거나 낮은 버전
- '>' 명시된 버전보다 높은 버전 (''제외)
- => 명시된 버전보다 같거나 높은 버전
고급 범위 지정 (Advanced Range Syntax)
- ~ 사용하는 Hyphen Ranges X.Y.Z - A.B.C
- x 를 사용하는 X-Ranges 1.2.x 1.X 1.2.*
- ~를 사용하는 Tilde Ranges ~1.2.3 ~1.2 ~1
- ^를 사용하는 Caret Ranges ^1.2.3 ^0.2.5 ^0.0.4
참고 링크
https://semver.org/lang/ko/#spec-item-7
https://spoqa.github.io/2012/12/18/semantic-versioning.html
