Semantic Versioning

 

개요

프로그램의 변화에 따라 의미 있고 적절한 버전을 붙여주기 위해, Semantic Versioning 이라는 버전 관리 규칙을 알아본다.

 

 

 

Semantic Versioning이란?

Semantic Versioning은 Github의 공동창업자인 Tom Preston-Werner가 위의 문제를 해결하기 위해 기존의 현안을 모아 만든 제안입니다. 스펙 문서는 RFC 2119에 의해 규칙을 표기하여 의미적 엄격함을 높이고, 패키지 개발 생명주기에 발생할 수 있는 여러 상황을 포괄적으로 담아 일관성과 유연성을 균형 있게 갖추고 있습니다.

 

 

 

0.1.0

• Major Version : 기존 api 변경 및 삭제 되거나 하위 호환이 되지 않는 버전
• Minor Version : 신규 기능이 추가되거나 개선되었고 하위 호환이 되는 버전
• Patch Version : 버그 수정이 되었고 하위 호환이 되는 버전

 

 

규칙

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

 

 

요약

• 개발을 시작할 때 0.1.0 버전으로 시작한다.
• 오픈 시 1.0.0 으로 출시한다.
• 변경 내역에 따라 Major, Minor, Patch를 구분하여 버전을 수정한다.

 

 

참고 링크

https://spoqa.github.io/2012/12/18/semantic-versioning.html

https://semver.org/lang/ko/