소프트웨어 버전은 일반적으로 A.B.C 형식으로 작성
소프트웨어의 변화와 업데이트 수준을 간결하게 전달할 수 있음
이 체계는 사용자가 소프트웨어의 상태를 쉽게 파악하고, 개발자가 개발 및 유지보수를 체계적으로 관리하도록 돕는다.
버전 번호의 구조: Major.Minor.Patch
1. Major (주요 버전)
소프트웨어에 큰 변화가 있을 때 사용
새로운 기능의 추가, 기존 기능의 대대적인 개편, 또는 호환성이 깨지는 변경사항을 나타냄
• 이전 버전과의 호환성이 보장되지 않을 가능성이 큼
• 사용자와 개발자 모두가 변경사항에 주의를 기울여야 함
예시: 1.0.0 → 2.0.0 (큰 변화가 있는 메이저 업데이트)
2. Minor (부 버전)
주요 버전 안에서 새로운 기능이 추가되거나 기존 기능이 개선될 때 사용
• 기존 호환성 유지를 전제로 함
• 새로운 기능이 추가되더라도 안정성이 유지
예시: 1.0.0 → 1.1.0 (새로운 기능이 추가된 부 업데이트)
3. Patch (패치 버전)
버그 수정, 보안 취약점 해결, 또는 사소한 코드 변경사항을 나타냄
• 기존 기능의 안정성을 향상시키는 업데이트
• 완전한 호환성 유지를 목표로 함
예시: 1.0.0 → 1.0.1 (버그 수정 및 마이너 패치)
버전 체계의 목적과 중요성
• 정보 전달의 명확성
버전 번호를 통해 개발자와 사용자는 변경사항의 규모와 성격을 즉시 파악할 수 있음
예: 2.1.5 → 3.0.0으로 업데이트될 경우, 큰 변화와 호환성 문제를 예상할 수 있음
• 업데이트 관리의 효율성
사용자는 Patch 버전일 경우 즉시 업데이트를 진행하지만, Major 버전은 신중히 검토함
개발자는 각 버전 번호에 맞는 변경 사항을 체계적으로 관리할 수 있음
• 신뢰성과 품질 유지
버전 체계를 통해 안정성 향상을 위한 업데이트를 효과적으로 제공하며, 사용자는 이를 신뢰할 수 있음
추가적인 버전 번호 사용 사례
• Pre-release (사전 출시 버전):
1.0.0-alpha 또는 2.0.0-beta와 같은 형식으로 사용되며, 개발 중인 소프트웨어의 테스트 버전을 나타냄
• Build Metadata (빌드 메타데이터):
1.0.0+20230101처럼 사용되며, 특정 빌드 정보를 포함해 내부적으로 관리됨
버전 번호는 단순한 숫자가 아닌, 소프트웨어의 상태와 방향성을 보여주는 중요한 지표
이를 통해 사용자와 개발자 간의 소통,신뢰 구축 가능