유의적 버전 (Semantic Versioning). 버전 관리

버저닝

버전 번호는 소프트웨어의 변경사항을 나타내며, 
개발자와 사용자가 소프트웨어의 상태를 쉽게 이해하고 관리할 수 있도록 도와준다.

 

일반적인 버전 번호는 보통 세부분으로 나누어지며 아래와 같은 형태를 가진다.

 

MAJOR.MINOR.PATCH

1.2.20

 

 

 

세상엔 정말 다양한 버전 관리 방법이 있으며, 그 중 Semantic Versioning이 특히 오픈 소스 프로젝트에서 매우 널리 사용된다.

그래서 오늘은 이것에 대해 정리해보고자 한다.

 

유의적 버전 (Semantic Versioning) 

위의 시맨틱 버저닝의 경우, 깃헙의 공동창업자인 Tom Preston-Werner이 만든 규칙이며, 아래 공식사이트에서 상세한 내용들을 읽어볼 수 있다.

https://semver.org/

이 글에선 이에 대해 요약해보려한다.

 

 

기본 규칙

버전 번호는 MAJOR.MINOR.PATCH 형식을 따른다.

• MAJOR: 주요 변경 사항을 나타낸다. 이전 버전과 호환되지 않는 변경이 있을 때 증가한다.
• MINOR: 새로운 기능이 추가되었지만, 이전 버전과 호환되는 경우 증가한다.
• PATCH: 버그 수정이나 보안 업데이트와 같은 작은 변경 사항이 있을 때 증가한다.

 

상세 규칙

 

• 0.y.z 버전 : 초기 개발 단계에서는 버전 번호는 0.y.z로 설정한다. 여기서 y와 z는 초기 개발 단계에서 적절히 증가한다.
  0.y.z 버전은 안정적인 API를 제공하지 않는다는 것을 의미한다.
• 1.0.0 버전 : 1.0.0 버전은 공개 API가 안정적이라는 것을 의미한다. 이 시점부터 Semantic Versioning 규칙이 엄격히 적용된다.
• MAJOR 버전 증가 : MAJOR 버전이 증가할 때는 이전 버전과 호환되지 않는 변경 사항이 포함된다. 예를 들어, API의 중요한 부분이 변경되거나 제거될 때 MAJOR 버전이 증가한다.
• MINOR 버전 증가 : MINOR 버전이 증가할 때는 새로운 기능이 추가되지만, 이전 버전과 호환성을 유지한다. 이 경우 새로운 기능은 기존의 기능을 방해하지 않는다.
• PATCH 버전 증가 : PATCH 버전이 증가할 때는 버그 수정이나 보안 패치와 같은 작은 변경 사항이 포함된다. 이러한 변경 사항은 기존의 기능을 방해하지 않고, 호환성을 유지한다.
• 사전 릴리즈 (Pre-release Versions) : 사전 릴리즈 버전은 정식 릴리즈 전에 공개되는 버전이다. 이는 일반적으로 -alpha, -beta, -rc(release candidate) 등의 접미사를 붙여 나타낸다. 예를 들어, 1.0.0-alpha, 1.0.0-beta, 1.0.0-rc.1 등이 있다.
  • 사전 릴리즈 버전은 정식 릴리즈보다 낮은 우선순위를 가집니다. 예를 들어, 1.0.0-alpha는 1.0.0보다 낮은 버전이다.
  • 접미사는 점(.)으로 구분하여 추가 정보를 제공할 수 있다. 예를 들어, 1.0.0-alpha.1과 1.0.0-alpha.2는 첫 번째와 두 번째 알파 릴리즈를 나타냅니다.
• 빌드 메타데이터 (Build Metadata) 빌드 메타데이터는 빌드나 배포 정보를 추가로 포함할 수 있다. 이는 + 기호 뒤에 추가되며, 버전 우선순위에는 영향을 미치지 않는다. 예를 들어, 1.0.0+build2012는 1.0.0과 동일한 버전이지만, 추가 빌드 정보를 포함한다.

 

 

 

사전 릴리즈 (Pre-release Versions) 에 대한 내용들

위에서 언급된 사전릴리즈에 관련하여,, 

오픈소스 프로젝트들을 둘러보면 아래와 같은 단어들이 버전에 붙는 것을 자주 볼 수 있다.

1.0.0-alpha.1,  1.0.0-beta, 1.0.0-rc.1

 

이들은 각각 다음과 같은 뜻을 가진다.

 

Alpha (알파)

• 사용 시기: 소프트웨어의 초기 테스트 단계에서 사용된다. 이 단계에서는 새로운 기능이 첫 번째로 테스트되며, 많은 버그와 미완성 기능이 존재할 수 있다.
• 목적: 초기 사용자 피드백을 얻고, 크고 근본적인 문제를 해결하기 위해 사용된다.
• 예시: 1.0.0-alpha, 1.0.0-alpha.1 (첫 번째와 두 번째 알파 릴리즈)

Beta (베타)

• 사용 시기: 알파 테스트를 통과한 후, 소프트웨어가 더 넓은 범위의 사용자에게 테스트되는 단계이다. 이 단계에서는 기능이 거의 완성되고, 세부적인 버그 수정과 최적화가 주로 이루어진다.
• 목적: 더 넓은 사용자 기반으로부터의 실제 사용 사례를 통해 추가 피드백을 수집하고, 소프트웨어의 안정성을 높이기 위함.
• 예시: 1.0.0-beta, 1.0.0-beta.2 (첫 번째와 두 번째 베타 릴리즈)

Release Candidate (릴리즈 후보, RC)

• 사용 시기: 베타 테스트를 통과한 후, 최종 릴리즈 전에 발견될 수 있는 마지막 버그를 수정하기 위한 단계이다. 이 단계에서는 모든 기능이 완성되어 있으며, 주로 버그 수정과 성능 향상에 초점을 맞춘다.
• 목적: 최종 사용자 릴리즈 전에 소프트웨어의 안정성을 확보하는 것.
• 예시: 1.0.0-rc.1, 1.0.0-rc.2 (첫 번째와 두 번째 릴리즈 후보)

Nightly Builds (나이틀리 빌드)

• 사용 시기: 매일 개발 중인 최신 코드를 자동으로 빌드하여 생성되는 버전이다. 이 빌드는 개발이 진행되는 동안 지속적으로 업데이트되며, 가장 최신의 기능이나 수정 사항을 포함한다.
• 목적: 개발자들이 최신 변경 사항에 대해 빠르게 테스트하고 반응할 수 있게 하기 위함.
• 예시: 빌드 메타데이터를 사용하여 날짜나 빌드 번호를 포함시킬 수 있다. 예를 들어, 1.0.0+20240623 (2024년 6월 23일의 나이틀리 빌드)

 

 

 

예시

 

• 0.1.0: 초기 개발 단계. 안정적인 API를 제공하지 않음.
• 1.0.0: 첫 번째 안정 버전. 공개 API가 확립됨.
• 1.1.0: 새로운 기능이 추가된 버전. 기존 기능과 호환됨.
• 1.1.1: 버그가 수정된 버전. 기존 기능과 호환됨.
  • ex) 기존 버전과 호환되며, 검색 기능이 추가됨.
• 2.0.0: 주요 변경 사항이 포함된 버전. 이전 버전과 호환되지 않음.
  • ex) 기존 인증 시스템을 완전히 새로운 시스템으로 교체하여 이전 버전과 호환되지 않음
• 1.0.0-alpha: 1.0.0 버전의 알파 릴리즈.
• 1.0.0-beta: 1.0.0 버전의 베타 릴리즈.
• 1.0.0-rc.1: 1.0.0 버전의 첫 번째 릴리즈 후보.
• 1.0.0+202406231600: 1.0.0 버전과 동일하지만, 빌드 메타데이터가 포함된 버전 *(2024년 6월 23일의 나이틀리 빌드)

 

 

 

npm 사용 예시

 

npm으로 버전관리를 할 경우,

 

아래 명령어들을 통해 각각의 버전을 올릴수 있다.

 

npm version major

npm version minor

npm version patch

 

보통 릴리즈 브랜치로 코드가 올라가기 직전 위 명령어를 통해 코드의 브랜치를 관리한다.