Semantic Versioning

이번 포스트에서는 소프트웨어 개발 진행 시 겪게 되는 Versioning 문제에 대해서 서론하고, Versioning 방법인 Semantic Versioning에 대해서 설명한다.

Software Versioning

소프트웨어 버전 작성(Software Versioning)은 컴퓨터 소프트웨어의 특정 상태에 대해서 정의를 하는 것이다. 개발자가 소프트웨어 특정 상태를 기록하기 위한 필수적인 사항이다. 버전이라는 구분 방식은 많은 문제(소프트웨어의 상태 혼동 등)를 해결해주었지만 개발자들의 버전 작성 방식의 시점은 제각각 달랐기 때문에 또 다른 문제를 야기했다. 그래서 소프트웨어 버전 작성 방법이 제안됐다. 여러 가지 방법이 있지만 그중 Semantic Versioning이 대세적이다. 이번 포스트에서는 Semantic Versioning에 대해 설명한다.

Semantic Versioning

Semantic Versioning은 Github의 공동 창업자인 Tom Preston-Werner가 소프트웨어 버전 작성 규칙을 정하기 위해 제안한 방법이다. 아래는 Semantic Versioning(v2.0.0-rc1)에 대한 내용이다.

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

2. 일반 버전 명은 반드시 X.Y.Z 형태로 나타내며, 음이 아닌 정수이어야 한다. X는 Major, Y는 Minor, Z는 Patch 버전이며 1씩 증가한다.

3. Major 버전 숫자가 올라 갈 때, Minor 버전 숫자와 Patch 버전 숫자는 0으로 초기화 되어야 한다.

4. 버전명이 주어진 패키지가 한번 공개되면 해당 버전의 내용은 절대로 수정되어선 안된다. 어떠한 수정도 반드시 새로운 버전으로 공개되어야 한다.

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

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

6-1. Patch 버전(Z)은 하위 호환되며 버그 수정 시 올라간다.
6-2. Minor 버전(Y)은 기존 공개 API가 하위 호환되고 새로운 기능, 개선이 추가되거나 공개 API 하나 이상 deprecate될 시에도 올라가야 한다. 부가적인 새 기능이나 개선이 내부 코드에 있을 시에도 올릴 수 있다.
6-3. Major 버전(X)은 하위 호환되지 않는 변화가 추가될 때 올라간다.

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

예) 1.0.0-alpha < 1.0.0

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

예) 1.0.0+001 > 1.0.0

Reference

https://semver.org/
https://www.wikidata.org/wiki/Q48029236