본문 바로가기

개발(합니다)/방법론

[버전관리] Semantic Versioning(시맨틱 버전관리)와 Version Ranges

반응형

소프트웨어 생태계에서 버전에 대한 관리를 어떻게 할 것인지에 대한 방법론으로

시맨틱 버전 관리를 들 수 있습니다.

관련 정보는 아래 사이트에서 확인할 수 있으며 본 포스팅은 요약본입니다.
https://semver.org/lang/ko/


Semantic Versioning 이란

// 아래와 같은 형태를 가진다.
"devDependencies": {
    "react-test-renderer" : "^16.12.0",
}
  • Major Version : 기존 api 변경 및 삭제 되거나 하위 호환이 되지 않는 버전
  • Minor Version : 신규 기능이 추가되거나 개선돠었고 하위 호환이 되는 버전
  • Patch Version : 버그 수정이 되었고 하위 호환이 되는 버전

버전 관리를 함에 있어서 정해진 규칙 없이 제각각의 방식으로 관리하지 않고 규칙을 정해서 관리하기 위해 제안되었습니다.
Github의 공동창업자인 Tom Preston-Werner가 제안을 했습니다.
https://tom.preston-werner.com/

규칙(유의적 버전 2.0.0-ko2 기준)

1. 반드시 공개 API를 정의해야 하며 API는 코드 자체에 정의되어 있거나 명시적으로 문서화 되어야 한다.

2. 알번 버전 명은 반드시 X.Y.Z 형태로 나타내며 정수이고 X는 주요한 버전, Y는 작은 버전, Z는 패치버전이며 1씩 증가한다.

3. 주요버전(X)이 올라가면 작은 버전(Y)와 패치버전(Z)는 0으로 초기화 되어야하며 작은 버전(Y)가 올라가면 패치버전(Z)는 0으로 초기화 되어야 한다.

4. 버전명이 공개되면 버전의 내용은 절대로 수정되어서는 안 되며 어떠한 수정이 있더라도 새로운 버전으로 공개되어야 한다.

5. 주요 버전 0(0.Y.Z)는 초기 개발을 위한것이고 언제든 변경될 수 있으며 공개 API는 안전하지 않다고 여긴다.

6. 버전 1.0.0을 공개 API로 정의하고 이후 버전은 변경에 따라 결정한다.

  • 6-1. 패치 버전(Z)은 하위 호환되며 버그 수정 시 올라간다.
  • 6-2. 작은 버전(Y)는 기존 공개 API가 하위호환되고 새로운 기능, 개선이 추가되거나 공개 API 하나 이상이 deprecated가 되어도 올라가야 한다.
  • 6-3. 주요 버전(X)는 하위 호환되지 않는 변화가 생기면 올라간다.

7. 선행 배포 버전은 대시(-)와 점으로 나누어진 식별자들의 묶음을 패치 버전 뒤에 표시하며 식별자들은 ASCII영숫자와 대시만으로 구성되어야 하며 일반 버전보다 낮은 우선순위를 갖는다. 1.0.0-alpha < 1.0.0

8. 개발 버전은 더하기(+)와 점으로 누누어진 식별자들을 묶음을 패치 버전 뒤에 표시하며 일반 버전보다 높은 우선순위를 갖는다. 1.0.0+001 > 1.0.0

Node에서 쓰는 Version Range

일반 범위

  • < 명시된 버전보다 낮은 버전
  • <= 명시된 버전과 같거나 낮은 버전
  • 명시된 버전보다 높은 버전
  • = 명시된 버전보다 같거나 높은 버전

고급 범위

  • 사용하는 Hyphen Ranges : X.Y.Z~X1.X2.X3
    • 1.1.1 - 2.1.1 : >=1.1.1 <= 2.1.1 // 1.1.1과 같거나 커야하고 2.1.1보다 같거나 작아야 한다.
    • 1.1 - 2.1.1 : >=1.1.0 <= 2.1.1 // 1.1.0과 같거나 커야하고 2.1.1보다 같고나 작아야 한다.
    • 1.1.1 - 2.1 : >=1.1.1 < 2.1 // major, miner가 일치하는 경우만 포함
    • 1.1.1 - 2 : >= 1.1.1 < 3 // major가 일치하는 경우만 포함
  • x를 사용하는 X-Ranges : 1.0.x
    • * : >0.0.0 // 모든 버전 충족
    • 1.x : >=1.0.0 < 2.0.0 // major와 minor level의 업데이트 허용
    • 1.1.x : >=1.1.0 < 1.2.0 // patch level의 업데이트 허용
  • ~를 사용하는 Thlde Ranges : ~1.0.0
    • ~1.1.1 : >=1.1.1 < 1.2.9 // patch level 변경 허용
    • ~1.1 : >=1.1.1 < 1.2.0 // patch level 변경 허용
    • ~1 : >=1.0.0 < 2.0.0 // minor level 변경 허용
    • ~1.1.1-alpha.1 : >=1.1.1-alpha.1 < 1.2.0 // patch level 변경 허용하고 1.2.0-alpha.2.는 불포함
  • ^를 사용하는 Caret Ranges ^1.0.0
    • 간단 예시
      • 1.0.0 // minor와 patch 버전을 업데이트 허용
      • 1.x // patch 업데이트 허용
      • 1.x.x // 업데이트 거부
    • 상세 예시
      • ^1.1.1 : >=1.1.1 < 2.0.0 // 왼쪽에서 가장 처음 0이 아닌건 major이기에 minor와 patch 업데이트 허용
      • ^0.1.1 : >=0.1.1 < 0.3.0 // 왼쪽에서 가장 처음 0이 아닌건 minor이기에 patch 업데이트 허용
      • ^0.0.1 : >=0.0.1 // 왼쪽에서 가장 처음 0이 아닌건 patch이기에 업데이트 거부
      • ^1.1.1-beta.1 : >=2.0.0 // 왼쪽에서 가장 처음 0이 아닌건 major이기에 minor, patch 업데이트 허용
반응형