소프트웨어는 다른 수많은 소프트웨어들과의 협력을 통해서 효과적으로 기능을 수행하고있습니다. 간단한 프로젝트를 하나를 수행한다고 하더라도 수많은 패키지를 의존하게 되죠. 이러한 의존관계들이 평생 유지된다면 좋겠지만, 내가 사용하는 라이브러리가 업데이트되면서 여러 문제가 발생하기도 합니다. 지금까지 잘 작동하던 패키지가 업데이트를 진행하면서 사용법이나 동작 방식이 변해버리는 것이죠. 이런 문제를 효과적으로 해결하기 위해서 버전관리가 등장하게 되었습니다. 이제 우리는 버전을 보고 업데이트에 의한 의존성 문제를 예측하고 판단하며 대처할 수 있게 되었습니다.
이렇게 등장한 버전관리는 수많은 문제를 해결했지만 여전히 문제는 존재했습니다. 각 소프트웨어마다 사용하는 버전 이름짓기 방식이 달랐던 것이죠. 이러한 제각기의 버전명은 사용자가 버전의 변화를 직관적으로 해석하는데 어려움을 야기했습니다. 이를 해결하기 위해서 Github의 공동창업자인 Tom Preston-Werner가 기존의 버전관리 규칙들을 모아 Semantic Versioning를 제안입니다.
Seamantic Versioning
유의적 버전 명세
일반적인 규칙
- Seamantic Versioning을 사용하는 소프트웨어는 반드시 공개 API를 선언해야한다. 이 API는 코드 자체로 선언하거나 문서로 명시해야한다.
- 버전 번호는 반드시 (주버전 번호).(부버전 번호).(수버전 번호)의 형태로 만들어야 하며, 각 번호는 항상 증가해야한다.
- (주버전 번호)가 바뀌면 (부버전 번호),(수버전 번호)을 0의로, (부버전 번호)가 바뀌면 (수버전 번호) 0으로 초기화한다.
- 특정 버전으로 패키지를 배포하고 나면, 그 내용은 절대 변하지 않아야 한다.
- 버전 번호 앞에 0을 붙이지 않는다.(버전 번호 자체가 0인 경우를 제외)
버전의 증가 기준
- 주버전 번호 증가 : 기존 API와 호환되지 않는 큰 변화가 있는 경우
- 부버전 번호 증가 : 기존 버전과 호환되는 새로운 기능을 추가하는 경우
- 수버전 번호 증가 : 기존 버전과 호환되는 버그 수정의 경우
pre-release버전 규칙
- pre-release버전은 기존의 버전 뒤에 수버전 바로 뒤에 붙임표(-)를 붙이고 마침표(.)로 구분된 식별자를 더해서 표시한다. 이때 pre-release버전 번호는 숫자, 알파벳, 붙임표로 구성된다. (예: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.)
빌드 메타데이터
빌드 메타데이터란?
git commit 후 생기는 난수가 붙는 경우가 있는데, 그 상태로 그대로 배포하는 경우 build metadata가 그것이다.
- 빌드 메타데이터는 수버전이나 정식배포 전 식별자 뒤에 더하기(+) 기호를 붙인 뒤에 마침표로 구분된 식별자를 덧붙여서 표현한다.
예) 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.
버전의 우선순위
- 우선순위는 주(major), 부(minor), 수(patch) 순서로 차례로 비교하면서, 차이가 나는 부분이 나타나면 결정된다.
- 주, 부, 수 버전이 같을 경우, pre-release 버전이 표기된 경우의 우선순위가 더 낮다.
- 주, 부 및 패치 버전이 동일한 두 가지 pre-release 버전의 우선 순위는 다음과 같이 차이점이 발견될 때까지 점으로 구분된 각 식별자를 왼쪽에서 오른쪽으로 비교하여 결정해야 한다.
- 숫자로만 구성된 식별자는 숫자로 비교한다.
- 문자나 하이픈이 있는 식별자는 ASCII 정렬 순서로 사전적으로 비교한다.
- 숫자 식별자는 항상 숫자가 아닌 식별자보다 우선 순위가 낮다.
- 이전의 모든 식별자가 동일한 경우 더 큰 시험판 필드 집합이 더 작은 집합보다 우선 순위가 높다.
예: 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.
0.0.0과 1.0.0
- 주버전 0(0.y.z)은 초기 개발을 위해서 쓴다. 아무 때나 마음대로 바꿀 수 있다.
- 최초 개발 배포를 0.1.0으로 하고, 이후 배포마다 부버전을 올린다.
- 1.0.0 버전은 공개 API를 정의한다. 이후의 버전 번호는 이때 배포한 공개 API에서 어떻게 바뀌는지에 따라 올린다.
출처
https://velog.io/@i33w/semver
https://velog.io/@slaslaya/Semantic-Versioning-2.0.0-MAJOR-MINOR-PATCH%EC%99%80-%EB%AA%85%EC%84%B8%EC%97%90-%EA%B4%80%ED%95%98%EC%97%AC
https://semver.org/lang/ko/
https://kiwinam.com/posts/33/version-naming/