소프트웨어 버전 규칙

반응형

 

소프트웨어 버전 규칙

본 글에서는 개발 중인 또는 개발 완료된 소프트웨어의 버전 할당에 관련된 규칙을 정의한다.

 

소프트웨어에 할당하는 버전은 기본적으로 유의적 버전 2.0.0-ko2에 소개된 버전 규칙을 따른다.

 

본 글은 유의적 버전 2.0.0-ko2에 기술된 내용을 그대로 옮겼으며, 해당 내용에서 삭제된 부분은 취소선, 새롭게 추가된 부분은 녹색 글씨로 표시하였다.

 

유의적 버전 2.0.0

요약

버전을 주.부.수 숫자로 하고:

 
1. 기존 버전과 호환되지 않게 API가 바뀌면 “주(主, Major) 버전”을 올리고,
2. 기존 버전과 호환되면서 새로운 기능을 추가할 때는 “부(部, Minor) 버전”을 올리고,
3. 기존 버전과 호환되면서 버그를 수정한 것이라면 “수(修, Patch) 버전”을 올린다.
 
주.부.수 형식에 정식배포 전 버전이나 빌드 메타데이터를 위한 라벨을 덧붙이는 방법도 있다.

 

 

머리말

소프트웨어 관리의 세계에는 “의존성 지옥”이라 불리는 성가신 문제가 있다. 시스템 규모가 커질수록, 그리고 더 많은 패키지를 가져다 쓸수록, 언젠가, 이 절망의 늪에 빠진 자신을 발견하기 쉽다.

 
의존성이 높은 시스템에서는, 새 패키지 버전을 배포하는 일이 금방 끔찍해지곤 한다. 의존성 명세를 너무 엄격하게 관리하면, 버전에 갇히게 될 위험이 있다(의존하는 모든 패키지의 새 버전을 배포하지 않고는 업그레이드할 수 없게 된다). 의존성을 너무 느슨하게 관리하면, 버전이 엉켜서 괴롭게 될 것이다(지나치게 나중 버전까지 호환될 거라 가정한 경우). 버전에 갇히거나 엉켜서 쉽고 안전하게 프로젝트를 계속 진행할 수 없다면 의존성 지옥에 빠진 것이다.
 
이 문제의 해결책으로, 버전 번호를 어떻게 정하고 올려야 하는지를 명시하는 규칙과 요구사항을 제안한다. 이 규칙들은 기존 오픈 소스/비공개 소스 소프트웨어에 널리 활용되는 규칙을 바탕으로 했으나, 반드시 따르고자 제약을 받지는 않았다. 이 시스템이 동작하려면, 먼저 공개(public) API를 선언해야 한다. 문서와 소스 코드 자체로 드러낼 수 있다. 어떤 방식이든 API가 명확해야 한다. 한번 공개 API를 정의하고 나면, 버전 번호를 올리는 방식을 통해 API가 어떻게 바뀌는지 표현한다. 버전을 X.Y.Z (주.부.수) 형식으로 정한다. API에 영향이 없는 버그 수정은 수(修)버전을 올리고, API가 호환되면서 바꾸거나 추가하는 경우에는 부(部)버전을 올리고, API가 호환되지 않는 변경이라면 주(主)버전을 올린다.
 
이 체계를 “유의적 버전”이라고 부르고자 한다. 이 체계를 따르면, 버전 번호와 그 번호를 바꾸는 방법을 통해 특정 버전에서 다음 버전으로 넘어가면서 코드가 어떻게 바뀌는지를 드러낸다.

 

 

유의적 버전 명세 (SemVer)

1. 공개 API 선언

  • 유의적 버전을 쓰는 소프트웨어는 반드시 공개 API를 선언한다. 이 API는 코드 자체로 선언하거나 문서로 엄격히 명시해야 한다. 어떤 방식으로든, 정확하고 이해하기 쉬워야 한다.
 

 

2. 버전 번호 형식

  • 보통 버전 번호는 반드시 X.Y.Z의 형태로 한다. X, Y, Z는 각각 자연수(음이 아닌 정수)이고, 절대로 0이 앞에 붙어서는 안 된다. 
  • X는 주(主, Major)버전 번호이고, Y는 부(部, Minor)버전 번호이며, Z는 수(修, Patch)버전 번호이다. 
  • 각각은 반드시 증가하는 수여야 한다. 예: 1.9.0 -> 1.10.0 -> 1.11.0.
 
 
3. 금지 사항
  • 특정 버전으로 패키지를 배포하고 나면, 그 버전의 내용은 절대 변경하지 말아야 한다
  • 변경분이 있다면 반드시 새로운 버전으로 배포하도록 한다.
 
 
4. 초기개발 버전
  • 주버전 0(0.y.z)은 초기 개발을 위해서 쓴다. 아무 때나 마음대로 바꿀 수 있다. 
  • 이 공개 API는 안정판으로 보지 않는 게 좋다.
 
 
5. 최초 배포 버전
  • 1.0.0 버전은 공개 API를 정의한다. 
  • 이후의 버전 번호는 이때 배포한 공개 API에서 어떻게 바뀌는지에 따라 올린다.
 
 
6. 수버전 증가 조건
  • 수버전 Z (x.y.Z | x > 0)는 반드시 그 전 버전 API와 호환되는 버그 수정의 경우에만 올린다. 
  • 버그 수정은 잘못된 내부 기능을 고치는 것이라 정의한다.
 
 
7. 부버전 증가 조건
  • 공개 API에 기존과 호환되는 새로운 기능을 추가할 때는 반드시 부버전 Y(x.Y.z | x > 0)를 올린다. 
  • 공개 API의 일부를 앞으로 제거할 것(deprecate)으로 표시한 경우에도 반드시 올리도록 한다. 
  • 내부 비공개 코드에 새로운 기능이 대폭 추가되거나 개선사항이 있을 때도 올릴 수 있다. 
  • 부버전을 올릴 때 수버전을 올릴 때만큼의 변화를 포함할 수도 있다. 
  • 부버전이 올라가면 수버전은 반드시 0에서 다시 시작한다.
 
 
8. 주버전 증가 조건
  • 공개 API에 기존과 호환되지 않는 변화가 있을 때는 반드시 주버전 X(X.y.z | X > 0)를 올린다. 
  • 부버전이나 수버전급 변화를 포함할 수 있다. 
  • 주버전 번호를 올릴 때는 반드시 부버전과 수버전을 0으로 초기화 한다.
 
 
9. 사전 배포(pre-release) 버전 형식
  • 수버전 바로 뒤에 붙임표(-)를 붙이고 마침표(.)로 구분된 식별자를 더해서 정식 배포를 앞둔 (pre-release) 버전을 표기할 수 있다. 
  • 식별자는 반드시 아스키(ASCII) 문자, 숫자, 붙임표로만 구성한다[0-9A-Za-z-]. 식별자는 반드시 한 글자 이상으로 한다. 숫자 식별자의 경우 절대 앞에 0을 붙인 숫자로 표기하지 않는다. 
  • 식별자는 a1, a2, a3, ... 형식으로 지정한다. 예: 3.2.1-a1, 3.2.1-a2
  • 정식배포 전 버전은 관련한 보통 버전보다 우선순위가 낮다. 
  • 정식배포 전 버전은 아직 불안정하며 연관된 일반 버전에 대해 호환성 요구사항이 충족되지 않을 수도 있다. 예: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
 
 
10. 빌드 메타데이터 
  • 빌드 메타데이터는 수버전이나 정식배포 전 식별자 뒤에 더하기(+) 기호를 붙인 뒤에 마침표로 구분된 식별자를 덧붙여서 표현할 수 있다. 
  • 식별자는 반드시 아스키 문자와 숫자와 붙임표로만 구성한다 [0-9A-Za-z-]. 식별자는 반드시 한 글자 이상으로 한다. 
  • 식별자는 커밋해시 값의 앞부분을 사용하며, 최소 6자리 이상의 수를 사용한다. 예: 3.2.1+30fcc6
  • 빌드 메타데이터는 버전 간의 우선순위를 판단하고자 할 때 반드시 무시해야 한다. 그러므로, 빌드 메타데이터만 다른 두 버전의 우선순위는 같다. 예: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.
 
 
11. 버전 우선순위
  • 우선순위는 버전의 순서를 정렬할 때 서로를 어떻게 비교할지를 나타낸다. 
  • 우선순위는 반드시 주, 부, 수 버전, 그리고 정식배포 전 버전의 식별자를 나누어 계산하도록 한다 (빌드 메타데이터는 우선순위에 영향을 주지 않는다). 
  • 우선순위는 다음의 순서로 차례로 비교하면서, 차이가 나는 부분이 나타나면 결정된다: 
    • 주, 부, 수는 숫자로 비교한다. 예: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. 
    • 주, 부, 수버전이 같을 경우, 정식배포 전 버전이 표기된 경우의 우선순위가 더 낮다. 예: 1.0.0-alphaa1 < 1.0.0. 
    • 주, 부, 수버전이 같은 두 배포 전 버전 간의 우선순위는 식별자 숫자가 클수록 높다. 예: a1 < a2. 반드시 마침표로 구분된 식별자를 각각 차례로 비교하면서 차이점을 찾는다: 숫자로만 구성된 식별자는 수의 크기로 비교하고 알파벳이나 붙임표가 포함된 경우에는 아스키 문자열 정렬을 하도록 한다. 
    • 숫자로만 구성된 식별자는 어떤 경우에도 문자와 붙임표가 있는 식별자보다 낮은 우선순위로 여긴다. 앞선 식별자가 모두 같은 배포 전 버전의 경우에는 필드 수가 많은 쪽이 더 높은 우선순위를 가진다. 예: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있음

댓글

Designed by JB FACTORY