버전을 의미있게, Semanctic Versioning

개요

대게의 소프트웨어는 개발되어 출시될 때 '버전 정보'를 가지고 출시됩니다. 그리고 우리는 소프트웨어가 지원하는 기능과 내가 사용하고자 하는 환경에서의 호환 여부에 따라 적절한 버전을 선택해서 사용합니다. 일반적인 소프트웨어 사용자라면 눈에 띄는 주 버전을 주의하는 것만으로도 문제가 없지만 개발자 입장에서는 그렇지 않습니다. 현대의 소프트웨어 규모가 커짐에 따라 많은 패키지를 가져다 쓰게되고, 자연스럽게 깊은 의존성 지옥에 빠지기 때문입니다. 이는 패키지 업데이트와 같은 의존성의 작은 변화가 소프트웨어 전체에 영향을 미칠 수 있음을 의미합니다. 

Gravatars의 창시자이자 GitHub의 공동창업자인 Tom Preston-Werner는 기존의 버전 표기법에 대해 "어떠한 형태로든 정식 명세를 따르지 않는다면 버전 관리는 무의미하다"라고 꼬집었으며, npm 또한 공식 문서를 통해 "Javascript 생태게를 건강하고 안정적이며 안전하게 유지하려면 소유하고 있는 npm 패키지를 크게 업데이트 할 때마다 의미 체계 버전 지정 사양을 따라야 한다"라고 얘기합니다. 여기서 말하는 의미 체계 버전 지정 사양이 곧 Semantic Versioning이며 SemVer이라고도 표현합니다.

유의적 버전

유의적 버전의 형태

구조

유의적 버전 공식 문서에 따르면 숫자로 이루어진 '주.부.수' 형태를 가집니다. 여기서 '주'는 Major를 의미하며 '부'와 '수'는 각각 Minor와 Patch를 의미합니다. 각 위치에 따른 버전 값은 아래의 조건으로 변경됩니다.

 

• Major: 이전 버전과 호환되지 않는 기능 추가 및 수정
• Minor: 이전 버전과 호환되는 새로운 기능 추가 및 수정
• Patch: 이전 버전과 호환되는 버그 수정 및 세세한 수정

명세

• 유의적 버전을 사용하는 소프트웨어는 반드시 공개 API를 정의합니다. 
• 버전 번호는 반드시 X.Y.Z의 구조를 가지며, 앞에 0이 붙지 않는 양수로 작성합니다.
• 특정 버전으로 배포되면 그 버전의 내용은 절대 변경하지 않습니다.
• 주 버전0(0.Y.Z)은 출시되기 전인 개발 단계에서만 사용하며, 출시 후에는 1.0.0이상의 버전을 사용합니다.
• 버전이 올라가면 뒷 자리의 버전은 모두 0으로 초기화됩니다. (ex 1.2.3 -> 1.3.0 또는 3.12.20 -> 4.0.0)

FAQ

공식 문서에서 FAQ의 일부를 발췌한 목록입니다.

 

- 공개 API의 아주 사소한 부분이 하위호환 되지 않는다고 주 버전을 매번 올려야 한다면, 어느새 42.0.0버전이 되지 않을까?

ㄴ 의존하는 코드가 많은 소프트웨어에 호환되지 않는 변화를 가볍게 적용해서는 안된다. 추가적인 비용이 어마어마해질 수 있다. 호환되지 않는 변경분을 배포하기 이전에 그에 대한 여파와 비용과 혜택을 충분히 고려하고 평가해야 한다.

 

- 공개 API 전체를 문서로 만드는 것은 일이 너무 많다

ㄴ 다른 사람들이 쓰게 하려고 만든 소프트웨어를 문서화 하는것은 프로 개발자로서의 책임이며, 프로젝트를 효율적으로 유지하기 위해 소프트웨어의 복잡성을 관리하는 일은 매우 중요한 일이다. 장기적으로 볼 때, 유의적 버전과 잘 정의한 공개 API는 관련된 모든 사람과 기능이 순주롭게 지낼 수 있도록 한다.

 

- 부 버전을 올리는데 실수로 호환되지 않는 변경이 들어갔다면 어떻게 해야하나?

ㄴ 즉시 문제를 해결하고 호환성이 깨진 부분을 복구해서 새 부부전을 배포한다. 이 경우라도 이미 배포된 버전을 변경해서는 안된다. 필요한 경우라면 문제가 되는 버전을 문서로 표시해서 사용자들로 하여금 주의하도록 한다.

 

- "v1.2.3"은 유의적 버전인가?

ㄴ 아니다. 그러나, 버전 숫자를 나타내기 위해 유의적 버전의 접두어로 "v"를 붙이기도 한다. 버전 관리 도구에서 "version"의 축약어로 "v"로 사용하는 것을 흔하게 볼 수 있는데 (git tag v1.2.3 -m "Release version 1.2.3")에서 "v1.2.3"은 tag name이고 유의적 버전은 "1.2.3"이다.