소프트웨어 릴리즈 버전 명시 방법

 

소프트웨어 릴리즈 버전 명시 방법

백링크

릴리즈 노트 | JIRA

목차

• 개요
• Semantic Versioning (SemVer)
• 버전 번호 증가 규칙
• Pre-release 및 Build Metadata
• 다양한 버전 명시 방식
• 버전 관리 도구 활용
• 버전 호환성 표기법
• 실무 적용 가이드

개요

소프트웨어 버전 관리는 개발과 배포 과정에서 필수적인 요소입니다. 일관된 버전 명시 방법을 통해 개발자와 사용자 모두가 소프트웨어의 변경 사항과 호환성을 쉽게 파악할 수 있습니다.

Semantic Versioning (SemVer)

가장 널리 사용되는 버전 명시 방법으로, MAJOR.MINOR.PATCH 형태를 따릅니다.

기본 구조

MAJOR.MINOR.PATCH
   1  .  2  .  3

<전체를 뒤엎을 변화>,<기능 수정, 기능 추가>,<버그, 내부 적 코드 보완>

각 버전 번호의 의미

MAJOR (주 버전)

• 정의: 호환되지 않는 API 변경이 있을 때 증가
• 증가 조건:
  • 기존 API를 제거하거나 변경
  • 기존 기능의 동작 방식이 완전히 변경
  • 이전 버전과 호환되지 않는 변경사항
  • 전면적인 아키텍처 변경

예시:

• 1.5.3 → 2.0.0: 메인 API 인터페이스 변경
• 3.2.1 → 4.0.0: 데이터베이스 스키마 호환성 파괴 변경

MINOR (부 버전)

• 정의: 하위 호환성을 유지하면서 새로운 기능을 추가할 때 증가
• 증가 조건:
  • 새로운 API 추가
  • 새로운 기능 추가
  • 기존 기능의 개선 및 확장
  • 사용자에게 도움이 되는 새로운 옵션 추가

예시:

• 2.1.4 → 2.2.0: 새로운 인증 방법 추가
• 1.3.2 → 1.4.0: 새로운 데이터 내보내기 기능 추가

PATCH (수정 버전)

• 정의: 하위 호환성을 유지하면서 버그를 수정할 때 증가
• 증가 조건:
  • 버그 수정
  • 보안 취약점 패치
  • 성능 개선 (기능 변경 없이)
  • 문서 오타 수정
  • 내부 코드 리팩토링

예시:

• 1.2.5 → 1.2.6: 로그인 오류 수정
• 3.1.0 → 3.1.1: 메모리 누수 문제 해결

---

버전 번호 증가 규칙

기본 원칙

1. MAJOR 증가 시 → MINOR와 PATCH를 0으로 리셋
2. MINOR 증가 시 → PATCH를 0으로 리셋
3. PATCH 증가 시 → 해당 번호만 증가

실제 적용 예시

1.0.0 → 1.0.1 (버그 수정)
1.0.1 → 1.1.0 (새 기능 추가)  
1.1.0 → 1.1.1 (버그 수정)
1.1.1 → 2.0.0 (호환성 파괴 변경)
2.0.0 → 2.0.1 (버그 수정)

---

Pre-release 및 Build Metadata

Pre-release 버전

정식 릴리즈 전 테스트 목적으로 사용하는 버전입니다.

1.0.0-alpha
1.0.0-alpha.1
1.0.0-beta
1.0.0-beta.2
1.0.0-rc.1

Pre-release 식별자

• alpha: 내부 테스트용, 불안정한 초기 버전
• beta: 공개 베타 테스트용, 기능은 완성되었으나 안정성 검증 중
• rc (Release Candidate): 릴리즈 후보, 최종 버전과 거의 동일

Build Metadata

빌드나 커밋 정보를 포함하는 메타데이터입니다.

1.0.0+20231201
1.0.0+exp.sha.5114f85
1.0.0-beta+exp.sha.5114f85

---

다양한 버전 명시 방식

Calendar Versioning (CalVer)

날짜를 기반으로 한 버전 체계입니다.

YYYY.MM.DD  → 2024.03.15
YYYY.MM     → 2024.03
YY.M.PATCH  → 24.3.1

사용 사례: Ubuntu (20.04, 22.04), Windows (Windows 10 version 2004)

Date-based Versioning

2024-03-15
20240315
2024.03.15.1

Marketing Versioning

마케팅이나 브랜드 목적의 버전 명시입니다.

Windows 11, macOS Sonoma, iOS 17
Chrome 120, Firefox 121

 

버전 관리 도구 활용

Git Tags

git tag v1.2.3
git tag -a v1.2.3 -m "Release version 1.2.3"

자동 버전 관리

conventional-changelog:

• 커밋 메시지 기반으로 자동 버전 증가
• feat: → MINOR 증가
• fix: → PATCH 증가
• BREAKING CHANGE: → MAJOR 증가

Package.json (Node.js)

{
  "version": "1.2.3",
  "scripts": {
    "version:patch": "npm version patch",
    "version:minor": "npm version minor", 
    "version:major": "npm version major"
  }
}

버전 호환성 표기법

범위 지정 (npm/yarn)

"^1.2.3"  // 1.2.3 <= 버전 < 2.0.0
"~1.2.3"  // 1.2.3 <= 버전 < 1.3.0
">=1.2.3" // 1.2.3 이상
"1.2.x"   // 1.2.0 <= 버전 < 1.3.0

Maven/Gradle (Java)

<version>[1.0,2.0)</version>  // 1.0 이상 2.0 미만
<version>[1.2.3,)</version>   // 1.2.3 이상

실무 적용 가이드

릴리즈 계획 수립

1. 기능 개발 → MINOR 증가 계획
2. 버그 수정 → PATCH 증가
3. 호환성 변경 → MAJOR 증가 (신중히 계획)

브랜치 전략과 버전

main/master     → 1.0.0, 1.1.0, 2.0.0
release/1.2     → 1.2.0, 1.2.1, 1.2.2  
hotfix/1.1.3    → 1.1.3

문서화 요구사항

• CHANGELOG.md: 버전별 변경사항 기록
• README.md: 현재 버전 및 호환성 정보
• API 문서: 버전별 API 변경사항

팀 내 합의사항 예시

MAJOR: 데이터베이스 스키마 변경, API 인터페이스 변경
MINOR: 새로운 API 엔드포인트, 새로운 설정 옵션
PATCH: 버그 수정, 보안 패치, 성능 개선