체계적인 버전 관리, SemVer

 요즘 솔루션의 버전을 보다 보면 SemVer을 도입하는 경우가 종종 보입니다.

 node.js에서는 SemVer를 따르고 있고 최근에 최종 버전이 발표된 Angular 2 에서도 SemVer를 따른다고 합니다.

 SemVer가 무엇인지, 어떤 방식으로 돌아가는 것인지 살펴봅니다.

자세한 내용은 [Semantic Versioning 2.0.0 스펙]을 참고했습니다.

---

 SemVer는 Semantic Versioning의 줄임말로, 버전 형식에 의미를 부여하여 좀 더 체계적인 버전 관리를 위한 제안입니다. 배포 정책이나 시기에 따라서 버전이 매겨지거나, 의미 없이 버전이 올라가는 것을 지양하며 버저닝에 대한 명확한 의미를 부여합니다.

 개발을 하다 보면 외부 라이브러리 의존성을 관리하기가 상당히 머리 아픈데, 버저닝에 대해 체계적인 기준이 있다면 버전만 보고서도 도입 여부를 판단하고 변경량을 짐작할 수 있습니다.

 핵심은 이렇습니다.

• 버전의 형식은 [Major].[Minor].[Patch] 형식으로 한다.
• 이전 버전과 호환되지 않는 API 변경은 MAJOR 버전 증가
• 이전 버전과 호환되면서 기능의 변경, 추가된 경우는 MINOR 버전 증가
• 버그 수정은 PATCH 버전 증가

 버전 형식을 3단계로 구분하면서 버전 숫자의 변동을 보고 이전 버전과 어느 정도 차이가 있는지 짐작할 수 있는 체계를 만들고 있습니다.

 예를 들어 외부 라이브러리의 1.3.5 버전을 쓰고 있다가 1.3.6 버전이 나왔다면 버그 수정을 위한 패치일테니 부담 없이 라이브러리를 업데이트 할 수 있을 것이고, 1.4.0이 나왔다면 조금 더 많은 내용이 변경되었지만 호환은 되는 범위이니 큰 부담은 없겠죠. 2.0.0 버전이 나왔다면 이전 버전과 호환이 되지 않는 큰 변화가 나온 것으로 파악하고 깊이 있는 검토가 필요하겠네요.

 이렇게 버전의 변화를 보고 변동량을 짐작할 수 있는 체계가 SemVer의 핵심입니다.

 스펙 문서에는 많은 내용들이 있지만... 요점만 추려보면 이런 내용도 있네요.

• SemVer를 사용하는 소프트웨어는 반드시 공개 API를 선언해야 한다. 이 API는 코드 자체로 선언하거나 문서로 명시해야 한다. 외부와 연결되는 API를 사용하니 API의 버전에 대한 명시는 당연하겠죠 ㅎ
• Major, Minor, Patch 각각의 버전은 자연수로 증가하고, 0이 앞에 붙어서는 안된다. 1.11.0과 같은 형식도 가능
• API가 이전 버전과 호환되지 않게 변경된 경우에는 반드시 Major 버전을 올린다. 이 때 Minor 버전과 Patch 버전은 0으로 초기화한다.
• Patch 버전 뒤에 하이픈(-)을 붙이고 마침표(.)로 구별된 식별자를 붙여 배포 전의 버전을 명명할 수 있다. 1.0.0-alpha, 1.0.0-alpha.1 과 같은 형식으로. 이 때, 정식배포 버전과 비교하면 정식배포 버전의 우선순위가 더 높다. 1.0.0-alpha < 1.0.0

 공식 문서에서도 이야기하고 있지만 이 방식은 새롭거나 혁신적인 아이디어는 아닙니다. 이미 비슷하게 적용하고 있을 수도 있죠. SemVer에서 지향는 것은, '비슷한' 방식이 아닌 '동일한' 체계의 버저닝입니다.

 버저닝에 대해서 깊이 있게 고민해보고 이렇게 직관적인 체계를 만든 것이 신기하네요. 개발자의 편의를 위해서는 좋은 방향으로 보입니다.

 세부적인 내용이나 FAQ는 공식 문서에 자세히 나와있으니, 공식 문서를 한 번씩 보는 것도 괜찮을 것 같습니다~

 SemVer의 내용이 직관적이고 명확해서, 이번 글은 간단하게 마무리 합니다 ㅎ