소프트웨어 버전 작성

소프트웨어 버저닝(software versioning)은 컴퓨터 소프트웨어의 고유한 상태에 고유한 버전 이름 또는 고유한 버전 번호를 할당하는 과정이다. 가장 널리 채택된 버전 번호 체계는 시맨틱 버저닝(SemVer)으로 알려져 있으며, 세 부분으로 구성된 버전 번호(주.부.패치), 선택적인 사전 릴리스 태그(예: 알파, 베타), 선택적인 빌드 메타 태그로 이루어진다. 어도비 플래시의 경우처럼 네 번째 숫자가 소프트웨어 빌드를 나타내는 데 사용될 수도 있다. 일부 회사는 로터스 1-2-3 릴리스 1a와 같이 캘린더 버저닝으로 알려진 시스템에서 빌드 날짜와 문자 및 기타 문자를 사용하기도 한다.

미디어위키를 포함한 대부분의 자유-오픈 소스 소프트웨어 패키지는 버전을 마침표로 구분된 일련의 개별 숫자로 취급하며, 1.8.1, 1.9.0과 같은 진행 방식을 따른다. 반면 일부 소프트웨어 패키지는 릴리스를 1.8, 1.81, 1.82와 같은 십진수로 식별한다. 개발자는 상당한 기능이 추가되었음을 나타내거나 마케팅 목적으로 여러 부 버전을 한 번에 건너뛸 수 있다. 버전 번호는 종종 소프트웨어 제품의 사본을 식별하고 협업 버전 관리 시스템에서 다른 사본과 비교하는 데 사용된다.

소프트웨어 개발 팀 내에서는 버전 관리를 사용하여 증분적으로 다른 버전의 정보를 추적하여 모든 변경 사항을 되돌릴 수 있도록 한다. 최신 컴퓨터 소프트웨어는 종종 두 가지 다른 소프트웨어 버저닝 체계를 사용하여 추적된다. 즉, 하루에 여러 번 증가할 수 있는 내부 버전 번호와 일반적으로 훨씬 덜 자주 변경되는 릴리스 버전이다.

역사적으로 파일 번호는 특히 공공 행정 및 기업에서 파일이나 사건을 고유하게 식별하는 데 사용되었다. 이러한 관행은 MIT의 ITS 파일 시스템에 의해 처음으로 컴퓨터 파일에 도입되었고, 나중에 1972년에 PDP-10용 TENEX 파일 시스템에 도입되었다. 21세기에는 더 많은 프로그래머들이 소프트웨어 라이브러리, 소프트웨어 프레임워크, 명령줄 응용 프로그램을 사용할 때 특히 유용한 시맨틱 버저닝 정책과 같은 표준화된 버전 정책을 사용하기 시작했다.

역사
파일 번호는 특히 공공 행정 및 기업에서 파일이나 사건을 고유하게 식별하는 데 사용되었다. 컴퓨터 파일의 경우 이러한 관행은 MIT의 ITS 파일 시스템에 의해 처음 도입되었고, 나중에 1972년에 PDP-10용 TENEX 파일 시스템에 도입되었다.

나중에 파일 목록과 해당 버전, 그리고 그들 간의 의존성이 추가되었다. Dpkg를 사용하는 데비안과 같은 리눅스 배포판은 일찍이 패키지 간의 의존성을 해결할 수 있는 패키지 관리 소프트웨어를 만들었다. 데비안의 첫 시도는 패키지가 자신에게 의존하는 다른 패키지를 아는 것이었다. 1994년부터 이 아이디어는 역전되어 패키지가 필요한 패키지를 알게 되었다. 패키지를 설치할 때 의존성 해결은 필요한 패키지도 자동으로 계산하고 원하는 패키지와 함께 설치하는 데 사용되었다. 업그레이드를 용이하게 하기 위해 최소 패키지 버전이 도입되었다. 따라서 번호 매김 체계는 어떤 버전이 필요한 버전보다 새로운지 알려야 했다.

체계
시퀀스 식별자 기반
섬네일|upright=0.5|버전 번호 시퀀스 예시
시퀀스 기반 소프트웨어 버저닝 체계에서 각 소프트웨어 릴리스에는 하나 이상의 숫자 또는 문자 시퀀스로 구성된 고유한 식별자가 할당된다. 이것이 공통점의 범위이다. 체계는 시퀀스 수, 개별 시퀀스에 의미 부여, 시퀀스 증가 방법과 같은 영역에서 크게 다르다.

 변경 중요도 
일부 체계에서는 시퀀스 기반 식별자가 릴리스 간 변경 사항의 중요도를 전달하는 데 사용된다. 변경 사항은 중요도 수준별로 분류되며, 릴리스 간에 어떤 시퀀스를 변경할지 결정하는 것은 이전 릴리스의 변경 사항 중요도를 기반으로 한다. 여기서 첫 번째 시퀀스는 가장 중요한 변경 사항에 대해 변경되고, 첫 번째 이후의 시퀀스 변경은 중요도가 감소하는 변경 사항을 나타낸다.

체계에 따라 중요도는 변경된 코드 줄 수, 추가 또는 제거된 기능 지점, 새 버전을 채택하는 데 필요한 작업 측면에서 고객에게 미치는 잠재적 영향, 버그 또는 선언되지 않은 중단 변경 위험, 시각적 레이아웃 변경 정도, 새로운 기능 수 또는 제품 개발자나 마케터가 중요하다고 판단하는 거의 모든 것(새 버전의 "상대적 우수성"을 강조하려는 마케팅 욕구 포함)으로 평가될 수 있다.
 시맨틱 버저닝 
 (일명 SemVer)은 세 부분으로 구성된 버전 번호(주.부.패치), 선택적인 사전 릴리스 태그, 선택적인 빌드 메타 태그로 버전을 인코딩하는 널리 채택된 버전 체계이다. 이 체계에서는 위험과 기능성이 중요도 측정 기준이 된다. 호환성이 깨지는 변경 사항은 주 버전 번호를 증가시켜 나타내고(높은 위험), 새로운 비호환 기능은 부 버전 번호를 증가시키며(중간 위험), 기타 비호환 변경 사항은 패치 번호를 증가시킨다(가장 낮은 위험). 사전 릴리스 태그(-alpha, -beta)의 존재는 상당한 위험을 나타내며, 주 버전 번호가 0(0.y.z)인 경우도 마찬가지이다. 이는 잠재적으로 호환성을 깨는 변경 사항이 어떤 수준이든 포함될 수 있는 작업 중인 상태(가장 높은 위험)를 나타내는 데 사용된다. SemVer 버전에서 호환성을 추론하는 예로, API 버전 2.1.5에 의존하는 소프트웨어는 버전 2.2.3과 호환되지만 3.2.4와는 반드시 호환되지 않는다.

 기타 체계 
어도비 플래시의 경우처럼 네 번째 숫자가 소프트웨어 빌드를 나타내는 데 사용될 수도 있다. 일부 회사에서는 로터스 1-2-3 릴리스 1a와 같이 빌드 날짜와 문자 및 기타 문자를 포함하기도 한다.

개발자는 상당한 기능이 추가되었음을 나타내기 위해 여러 부 버전을 한 번에 건너뛸 수 있지만, 주 버전 번호를 증가시킬 만큼 충분하지 않은 경우도 있다. 예를 들어 인터넷 익스플로러 5는 5.1에서 5.5로, 어도비 포토샵은 5에서 5.5로 변경되었다. 이는 소프트웨어 사용자에게 업그레이드의 가치를 강조하기 위해 또는 어도비의 경우처럼 주 버전 중간의 릴리스를 나타내기 위해 수행될 수 있다(그러나 시퀀스 기반 버저닝 수준이 반드시 한 자리 숫자에만 국한되는 것은 아니다. 블렌더 버전 2.91 또는 마인크래프트 자바 에디션 1.7.10부터 1.21.10까지와 같이, 이후 버전 관리 체계가 연도 기반 형식으로 전환되었다).

다른 접근 방식은 주 및 부 버전 번호와 릴리스 유형을 나타내는 영숫자 문자열을 사용하는 것이다. 예를 들어 "alpha"(a), "beta"(b) 또는 "release candidate"(rc)와 같다. 이 접근 방식을 사용하는 소프트웨어 릴리스 트레인은 0.5, 0.6, 0.7, 0.8, 0.9 → 1.0b1, 1.0b2 (일부 수정 사항 포함), 1.0b3 (더 많은 수정 사항 포함) → 1.0rc1 (충분히 안정적이라면), 1.0rc2 (더 많은 버그가 발견되면) → 1.0과 같이 보일 수 있다. 이 체계에서는 릴리스 후보 단계 동안 새로운 기능과 호환성이 깨지는 변경 사항을 잠그는 것이 일반적인 관행이며, 일부 팀의 경우 베타 버전조차도 버그 수정만 허용하여 목표 릴리스에 대한 수렴을 보장한다.

다른 체계는 개별 시퀀스에 의미를 부여한다.
major.minor[.build[.revision]] (예시: 1.2.12.102)
major.minor[.maintenance[.build]] (예시: 1.4.3.5249)

다시 말하지만, 이러한 예시에서 "주요" 변경 사항과 "부수적" 변경 사항을 구성하는 것에 대한 정의는 전적으로 주관적이며 작성자의 재량에 달려 있다. 마찬가지로 "빌드"를 정의하는 것이 무엇인지, "수정"이 "부수적" 변경 사항과 어떻게 다른지도 마찬가지이다.

리눅스 및 솔라리스의 공유 라이브러리는 current.revision.age 형식을 사용할 수 있다. 여기서:
current: 라이브러리가 구현하는 최신 인터페이스 번호.
revision: 현재 인터페이스의 구현 번호.
age: 라이브러리가 구현하는 최신 및 가장 오래된 인터페이스 간의 차이. 세 번째 필드의 이 사용은 libtool에 특화된 것이다. 다른 것들은 다른 의미를 사용하거나 단순히 무시할 수 있다.

책 출판에서도 상대적인 변경 중요도와 버전 명명법에 대한 유사한 문제가 존재하며, 판 번호 또는 이름은 다양한 기준에 따라 선택될 수 있다.

대부분의 독점 소프트웨어에서 소프트웨어 제품의 첫 번째 릴리스 버전은 버전 1이다.

 호환성 정도 
일부 프로젝트는 주 버전 번호를 사용하여 호환되지 않는 릴리스를 나타낸다. 두 가지 예는 아파치 포터블 런타임 (APR)과 FarCry CMS이다.

종종 프로그래머는 하위 호환성이 있는 새 소프트웨어를 작성한다. 예를 들어, IBM Z/OS는 동일한 시스플렉스에서 실행되는 3개의 연속적인 주 버전 운영 체제와 제대로 작동하도록 설계되었다. 이를 통해 고가용성 컴퓨터 클러스터를 실행하는 사람들은 한 번에 하나의 시스템이 종료, 업그레이드 및 서비스로 복원되는 동안 대부분의 컴퓨터를 계속 작동시킬 수 있다.

종종 패킷 헤더와 파일 형식에는 버전 번호가 포함된다. 때로는 작성한 소프트웨어의 버전 번호와 동일하고, 때로는 소프트웨어 버전 번호와 독립적인 "프로토콜 버전 번호"이다. 오래된 사용 중단된 프로토콜 및 파일 형식을 처리하는 코드는 종종 불필요한 코드로 간주된다.

 개발 단계 지정 
실험 단계의 소프트웨어 (알파 또는 베타)는 종종 시퀀스의 첫 번째("주요") 위치에 0을 사용하여 상태를 지정한다. 그러나 이 체계는 초기 단계에만 유용하며, 버전 번호가 이미 0을 넘어선 기존 소프트웨어의 향후 릴리스에는 유용하지 않다.

새로운 릴리스의 상태를 나타내는 데 여러 체계가 사용된다.
 영숫자 접미사는 시맨틱 버저닝에서 채택된 일반적인 체계이다. 이 체계에서는 버전에 상태를 나타내는 대시와 일부 영숫자가 붙는다.
 숫자 상태는 숫자를 사용하여 시퀀스의 일부인 것처럼 상태를 나타내는 체계이다. 일반적인 선택은 4자리 버저닝에서 세 번째 위치이다.
 숫자 90+는 숫자를 사용하는 또 다른 체계이지만, 이전 버전의 숫자 아래에 나타난다. 일반적으로 90 이상인 큰 숫자가 마지막 위치에 사용된다. 이는 폰트콘피그와 같은 오래된 오픈 소스 프로젝트에서 흔히 사용된다.

두 가지 순수 숫자 형식은 시맨틱 버저닝에서 발견되는 "alpha < beta < rc < no prefix" 비교를 처리하는 데 필요한 특별한 논리를 제거하지만, 명확성이 떨어지는 단점이 있다.

미디어위키를 포함한 대부분의 자유-오픈 소스 소프트웨어 패키지는 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2 등과 같이 점으로 구분된 일련의 개별 숫자로 버전을 처리한다. 반면 일부 소프트웨어 패키지는 1.7, 1.8, 1.81, 1.82, 1.9 등과 같이 십진수로 릴리스를 식별한다. 십진수 버전은 1980년대에 넷웨어, DOS, 마이크로소프트 윈도우와 같이 흔했지만, 2000년대에도 오페라와 무버블 타입에서 사용되었다. 십진수 체계에서 1.81은 1.8 다음의 부 버전이며, 유지 보수 릴리스(즉, 버그 수정만)는 1.81a 또는 1.81b와 같이 영문자 접미사로 표시될 수 있다.

표준 GNU 버전 번호 매기기 체계는 major.minor.revision이지만, 이맥스는 주 번호(1)를 생략하고 원래 이맥스 패키지에서는 항상 0이지만 배포자가 증가시키는 사용자 사이트 개정판이 추가된 다른 체계를 사용하는 주목할 만한 예이다. 유사하게, 데비안 패키지 번호는 버전 관리 체계를 변경할 수 있도록 선택적인 "에포크"로 접두사가 붙는다.

어떤 경우에는 개발자들이 주 버전 번호를 재설정하기로 결정할 수도 있다. 이는 새로운 개발 단계가 릴리스되었음을 나타내는 데 사용되기도 한다. 예를 들어, 마인크래프트 알파는 버전 1.0.0에서 1.2.6까지 실행되었고, 베타가 출시되었을 때 주 버전 번호가 재설정되어 1.0에서 1.8까지 실행되었다. 게임이 완전히 출시된 후 주 버전 번호는 다시 1.0.0으로 재설정되었다.

 형식 
일부 프로젝트에서는 음수 버전 번호를 사용한다. 한 가지 예는 -1.0에서 시작하여 0.0까지 올라가는 SmartEiffel 컴파일러이다.

정렬을 용이하게 하기 위해 일부 소프트웨어 패키지는 major.minor.release 체계의 각 구성 요소를 고정 너비로 나타낸다. Perl은 버전 번호를 부동 소수점 숫자로 나타낸다. 예를 들어, Perl의 5.8.7 릴리스는 5.008007로도 나타낼 수 있다. 이를 통해 이론적인 버전 5.8.10을 5.008010으로 나타낼 수 있다. 다른 소프트웨어 패키지는 각 세그먼트를 고정 비트 너비로 압축한다. 예를 들어, 마이크로소프트 윈도우에서 버전 번호 6.3.9600.16384는 십육진법 0x0006000325804000으로 나타낼 수 있다. 부동 소수점 체계는 버전 번호의 어떤 세그먼트가 999를 초과하면 작동이 중단되며, 각 16비트를 사용하는 압축 이진 체계는 65535 이후에 작동이 중단된다.

1.0과 2.6.x 시리즈 사이에 리눅스 커널은 홀수 부 버전 번호를 개발 릴리스를 나타내는 데 사용하고 짝수 부 버전 번호를 안정 릴리스를 나타내는 데 사용했다. 예를 들어, 리눅스 2.3은 리눅스 커널의 두 번째 주요 설계의 개발 제품군이었고, 리눅스 2.4는 리눅스 2.3이 성숙한 안정 릴리스 제품군이었다. 리눅스 커널의 부 버전 번호 다음에는 오름차순으로 릴리스 번호가 온다. 예를 들어, 리눅스 2.4.0 → 리눅스 2.4.22. 2004년 2.6 커널 릴리스 이후 리눅스는 더 이상 이 시스템을 사용하지 않으며, 훨씬 짧은 릴리스 주기를 갖는다.

동일한 홀수-짝수 시스템은 버전 0.12까지의 Node.js와 WineHQ와 같이 긴 릴리스 주기를 가진 다른 소프트웨어에서도 사용된다.

릴리스 날짜 식별자 기반
섬네일|CalVer 형식으로 릴리스 번호를 표시하는 스트리트 파이터 EX 스플래시 스크린: "961219 USA"
많은 프로젝트에서 캘린더 버저닝 (일명 CalVer)이라는 날짜 기반 버저닝 체계를 사용한다.

우분투는 캘린더 버저닝을 사용하는 프로젝트의 한 예이다. 예를 들어 우분투 18.04는 2018년 4월에 출시되었다. 이는 개발 일정 및 지원 타임라인과 쉽게 연결될 수 있다는 장점이 있다. 일부 비디오 게임도 버저닝에 날짜를 사용한다. 예를 들어 아케이드 게임인 스트리트 파이터 EX는 시작할 때 버전 번호를 날짜와 지역 코드로 표시한다. 예를 들어 961219 ASIA와 같다.

버전 관리에 날짜(예: 파일 이름)를 사용할 때는 ISO 8601 체계 YYYY-MM-DD를 사용하는 것이 일반적이다. 이는 오름차순 또는 내림차순으로 쉽게 문자열 정렬이 가능하기 때문이다. 하이픈은 때때로 생략된다. 와인 프로젝트는 이전에 연도, 월, 일 순으로 릴리스 날짜를 사용하는 날짜 버저닝 체계를 사용했다. 예를 들어 "Wine 20040505"와 같다. 마인크래프트의 초기 개발 빌드는 유사한 버전 형식이었지만 대신 DDHHMM을 사용했다. 예를 들어 rd-131655는 13일(2009년 5월) 16시 21분에 생성되었다.

마이크로소프트 오피스 빌드 번호는 인코딩된 날짜이다. 처음 두 자리는 프로젝트가 시작된 연도의 1월부터 경과한 개월 수를 나타내고(주요 오피스 릴리스마다 다른 프로젝트), 마지막 두 자리는 해당 월의 날짜를 나타낸다. 따라서 3419는 프로젝트가 시작된 연도 1월 이후 34번째 달의 19일이다.

연도를 사용하여 버전을 식별하는 다른 예로는 어도비 일러스트레이터 88 및 워드퍼펙트 오피스 2003이 있다. 연도가 버전을 나타내는 데 사용될 때, 일반적으로 마케팅 목적이며 실제 버전 번호도 존재한다. 예를 들어, 윈도우 95는 내부적으로 MS-DOS 7.00 및 윈도우 4.00으로 버전이 지정되어 있다. 마찬가지로 윈도우 2000은 내부적으로 NT 5.0으로 버전이 지정되어 있다.

 기타 체계 
일부 소프트웨어 제작사는 소프트웨어 릴리스를 나타내기 위해 다른 체계를 사용한다. 데비안 프로젝트는 운영 체제 릴리스에 주/부 버전 관리 체계를 사용하지만, 개발 중에는 토이 스토리 영화의 코드네임을 사용하여 안정, 불안정 및 테스트 릴리스를 참조한다.

BLAG Linux and GNU는 매우 큰 버전 번호를 특징으로 한다. 주요 릴리스는 50000 및 60000과 같은 번호를 가지며, 부 릴리스는 번호를 1씩 증가시킨다(예: 50001, 50002). 알파 및 베타 릴리스에는 주요 릴리스 번호보다 약간 작은 십진수 버전 번호가 부여된다. 예를 들어 버전 20000의 알파 1은 19999.00071이고, 버전 30000의 베타 2는 29999.50000이다. 2003년에 9001로 시작하여 가장 최신 버전은 140000이다.

어빗은 켈빈 버저닝(절대 켈빈 온도 척도에서 이름을 따옴)을 사용한다. 소프트웨어 버전은 높은 숫자에서 시작하여 버전 0으로 내려가며, 이 시점에서 소프트웨어는 완성된 것으로 간주되고 더 이상의 수정은 이루어지지 않는다.

사전 릴리스 버전
위에 나열된 다양한 버저닝 체계와 함께, 프로그램이 소프트웨어 배포 생명 주기 단계를 거치면서 사전 릴리스 버전을 나타내는 시스템이 일반적으로 사용된다.

초기 단계에 있는 프로그램은 종종 그리스어 알파벳의 첫 글자를 따서 "알파" 소프트웨어라고 불린다. 성숙했지만 아직 출시 준비가 되지 않은 프로그램은 그리스어 알파벳의 두 번째 글자를 따서 "베타" 소프트웨어라고 불릴 수 있다. 일반적으로 알파 소프트웨어는 개발자만 테스트하며, 베타 소프트웨어는 커뮤니티 테스트를 위해 배포된다.

일부 시스템은 1 미만의 숫자 버전(예: 0.9)을 사용하여 최종 "1.0" 릴리스에 접근하고 있음을 시사한다. 이는 오픈 소스 소프트웨어의 일반적인 관례이다. 그러나 사전 릴리스 버전이 기존 소프트웨어 패키지(예: 버전 2.5)에 대한 것이라면 버전 번호 뒤에 "a" 또는 "alpha"를 추가할 수 있다. 따라서 2.5 릴리스의 알파 버전은 2.5a 또는 2.5.a로 식별될 수 있다.

대안은 사전 릴리스 버전을 "릴리스 후보"로 지칭하는 것이다. 따라서 특정 버전으로 곧 출시될 소프트웨어 패키지는 해당 버전 태그 뒤에 "rc-#"을 붙여 릴리스 후보의 번호를 나타낼 수 있다. 최종 버전이 출시되면 "rc" 태그는 제거된다.

중요성

기술적 측면

 소프트웨어 공학에서 
버전 번호는 클라이언트 또는 소비자가 소프트웨어 제품의 사본을 개발자가 출시한 최신 버전과 같은 다른 사본과 식별하거나 비교하기 위해 실제적으로 사용된다. 프로그래머나 회사에게 버전 관리는 종종 수정 단위로 사용되며, 소프트웨어의 개별 부분이 동일한 부분의 최신 또는 이전 수정 사항과 비교 및 대조되는 경우가 많으며, 종종 협업 버전 관리 시스템에서 사용된다.

21세기에는 더 많은 프로그래머들이 시맨틱 버저닝 정책과 같은 공식화된 버전 정책을 사용하기 시작했다. 이러한 정책의 목적은 다른 프로그래머가 코드 변경으로 인해 작성한 내용이 손상될 가능성이 언제 있는지 알기 쉽게 만드는 것이다. 이러한 정책은 소프트웨어 라이브러리 및 소프트웨어 프레임워크에 특히 중요하지만, 명령줄 응용 프로그램(다른 응용 프로그램에서 호출될 수 있음) 및 기타 응용 프로그램(타사에서 스크립팅 및 확장될 수 있음)에도 매우 유용할 수 있다.

 릴리스 트레인 
소프트웨어 릴리스 트레인은 여러 제품에 대한 여러 개의 고유한 버전 소프트웨어 릴리스 시리즈가 정기적인 일정에 따라 여러 "트레인"으로 릴리스되는 소프트웨어 릴리스 일정의 한 형태이다. 일반적으로 각 제품 라인에는 특정 시간에 여러 개의 다른 릴리스 트레인이 실행되며, 각 트레인은 초기 릴리스부터 최종 성숙 및 폐기까지 계획된 일정에 따라 이동한다. 사용자는 프로덕션에 채택하기 전에 새로운 릴리스 트레인을 실험하여, 새로운 "원시" 릴리스를 일찍 실험할 수 있으며, 이전 트레인의 포인트 릴리스를 새로운 릴리스 트레인이 성숙해지기 전에 프로덕션 시스템에서 계속 따를 수 있다.

시스코의 IOS 소프트웨어 플랫폼은 수년 동안 많은 고유한 트레인을 가진 릴리스 트레인 일정을 사용했다. 최근에는 모질라 파이어폭스 및 안드로이드용 Fenix, Eclipse, 리브레오피스, 우분투, Fedora, 파이썬, digiKam 및 VM웨어를 포함한 많은 다른 플랫폼이 릴리스 트레인 모델을 채택했다.

 내부 버전 번호 
소프트웨어에는 제품 이름에 표시된 버전 번호와 다른 "내부" 버전 번호가 있을 수 있으며 (일반적으로 버전 번호 규칙을 더 일관되게 따른다). 예를 들어, Java SE 5.0에는 내부 버전 번호 1.5.0이 있으며, NT 4 이후의 윈도우 버전은 내부적으로 표준 숫자 버전을 계속 사용했다. 윈도우 2000은 NT 5.0, XP는 윈도우 NT 5.1, 윈도우 서버 2003 및 윈도우 XP 프로페셔널 x64 에디션은 NT 5.2, 윈도우 서버 2008 및 비스타는 NT 6.0, 윈도우 서버 2008 R2 및 윈도우 7은 NT 6.1, 윈도우 서버 2012 및 윈도우 8은 NT 6.2, 윈도우 서버 2012 R2 및 윈도우 8.1은 NT 6.3이다. 윈도우 10은 원래 NT 6.4로 의도되었으며, 공개된 초기 기술 미리보기 빌드 번호는 6.4.9841이었다. 그러나 이는 윈도우 10의 버전이 상업적 이름과 일치하도록 빠르게 인위적으로 10.0으로 증가했기 때문에 지속되지 않았고, 그 결과 운영 체제의 첫 출시 버전은 10.0.10240으로 번호가 매겨졌다. 그러나 윈도우 NT는 첫 출시가 3.1(당시 윈도우 출시 번호와 일치)로 번호가 매겨졌고, 윈도우 10 출시로 버전이 6.3에서 10.0으로 건너뛰었으므로 다섯 번째 주요 개정판에 불과하다는 점에 유의해야 한다.

 마케팅 
마케팅상의 이유로 버전 번호를 크게 건너뛰는 것은 비교적 흔한 관행이다. 때로는 소프트웨어 공급업체가 1.0 릴리스를 건너뛰거나 후속 버전 번호가 있는 릴리스를 빠르게 출시하는데, 이는 1.0 소프트웨어가 많은 고객에게 프로덕션 배포에 신뢰하기에는 너무 미성숙하다고 간주되기 때문이다. 예를 들어, dBase II의 경우, 제품이 실제보다 더 성숙한 것처럼 보이는 버전 번호로 출시된다.

때로는 경쟁사들의 버전 번호와 맞추기 위해 버전 번호가 증가하기도 한다. 이는 마이크로소프트, 아메리카 온라인, Sun 솔라리스, 자바 가상 머신, SCO 유닉스, 워드퍼펙트의 많은 제품 버전 번호 매기기 사례에서 볼 수 있다. 마이크로소프트 액세스는 버전 2.0에서 버전 7.0으로 건너뛰었는데, 이는 마이크로소프트 워드의 버전 번호와 맞추기 위함이었다.

마이크로소프트는 또한 "따라잡기" 버저닝의 대상이 되기도 했다. 넷스케이프 브라우저들은 마이크로소프트의 인터넷 익스플로러에 맞춰 버전 5를 건너뛰고 6으로 넘어갔지만, 사용자 에이전트 문자열에서 모질라 애플리케이션 스위트가 1.0 이전 개발 단계에서 버전 5를 상속했고 넷스케이프 6.x가 모질라의 코드 기반 위에 구축되었기 때문이기도 하다. 경쟁사들과 보조를 맞추는 또 다른 예는 슬랙웨어 리눅스가 1999년에 버전 4에서 버전 7로 건너뛴 경우이다.

이러한 접근 방식은 버전 번호 섹션의 의미론적 중요성을 훼손한다는 비판을 많이 받았지만, 모질라 (모질라 파이어폭스용) 및 구글 (구글 크롬용)을 포함한 점점 더 많은 공급업체에서 채택하고 있다.

 부 버전을 주 버전으로 홍보 
Sun의 자바는 때때로 하이브리드 시스템을 사용했는데, 내부 버전 번호는 항상 1.x였지만, 마케팅에서는 x만 참조했다.
 JDK 1.0.3
 JDK 1.1.2 ~ 1.1.8
 J2SE 1.2.0 ("Java 2") ~ 1.4.2
 Java 1.5.0, 1.6.0, 1.7.0, 1.8.0 ("Java 5, 6, 7, 8")

Sun은 또한 솔라리스의 경우 첫 번째 숫자를 생략하여 솔라리스 2.8 (또는 2.9)을 마케팅 자료에서 솔라리스 8 (또는 9)이라고 불렀다.

유사한 도약이 2010년대 초 아스테리스크 오픈 소스 PBX 구축 키트에서 일어났는데, 프로젝트 리더들은 현재 버전 1.8.x가 곧 버전 10으로 이어질 것이라고 발표했다.

 버전 번호의 정치적, 문화적 중요성 
 이정표로서의 버전 1.0 
자유 소프트웨어 및 오픈 소스 소프트웨어 커뮤니티는 소프트웨어를 일찍 그리고 자주 출시하는 경향이 있다. 초기 버전은 1 미만의 숫자를 가지며, 이러한 0.x 버전은 소프트웨어가 불완전하고 일반 출시 또는 현재 상태에서 사용하기에 충분히 안정적이지 않음을 전달하는 데 사용된다. 0.x 버전에서는 하위 호환되지 않는 변경 사항이 일반적이다. 버전 1.0은 주요 이정표로 사용되며, 소프트웨어가 최소한 개발자가 해당 버전에 넣고 싶었던 모든 주요 기능과 기능을 갖추고 있으며 일반 출시하기에 충분히 안정적이라고 간주됨을 나타낸다. 좋은 예로 1991년에 버전 0.01로 처음 출시된 리눅스 커널은 1994년까지 버전 1.0.0에 도달하는 데 걸렸다.

아케이드 게임 에뮬레이터 MAME의 개발자들은 이 프로그램의 버전 1.0을 출시할 의도가 전혀 없는데, 이는 항상 에뮬레이션할 아케이드 게임이 더 많을 것이고 따라서 프로젝트가 진정으로 완료될 수 없기 때문이다. 따라서 버전 0.99 다음에는 버전 0.100이 나왔다.

 미신 
 마이크로소프트 오피스의 오피스 2007 릴리스의 내부 버전 번호는 12였다. 다음 버전인 오피스 2010은 13이라는 숫자를 둘러싼 미신 때문에 내부 버전이 14이다. 비주얼 스튜디오 2013은 제품 버전 12.0이며, 새로운 버전인 비주얼 스튜디오 2015는 같은 이유로 버전 번호가 14.0이다.
 록시오 토스트는 버전 12에서 버전 14로 건너뛰었는데, 이는 13이라는 숫자를 둘러싼 미신을 건너뛰기 위함일 것이다.
 코렐의 워드퍼펙트 오피스는 버전 13을 "X3"(로마 숫자 10과 "3")으로 마케팅했다. 이 절차는 다음 버전인 X4까지 계속되었다. 코렐의 그래픽 스위트(즉, 코렐드로, 코렐 포토페인트)와 영상 편집 소프트웨어 "비디오 스튜디오"도 마찬가지였다.
 사이베이스는 Adaptive Server Enterprise 관계형 데이터베이스 제품에서 주요 버전 13과 14를 건너뛰고 12.5에서 15.0으로 바로 넘어갔다.
 ABBYY 링고 사전은 12, x3(14), x5(15) 번호 매김을 사용한다.
 SUSE 리눅스 엔터프라이즈는 버전 12 이후 버전 13과 14를 건너뛰고 2018년 7월에 SLES 15를 바로 출시했다.
 1990년대 중반, 급성장하는 CMMS인 Maximo는 Maximo Series 3에서 Series 5로 바로 넘어갔다. 이는 중국 시장에서 숫자 4가 "죽음"과 연관되어 마케팅상의 어려움이 있을 것으로 예상되어 Series 4를 건너뛴 것이다(참조: 4자 금기). 이것이 Maximo Series 5 버전 4.0의 출시를 막지는 못했다. (이후 "Series" 버저닝은 폐기되어 Series 5 버전 1.0 출시 후 버전 번호가 사실상 재설정되었다.)

 괴짜 문화 
 SUSE 리눅스 배포판은 더글러스 애덤스의 은하수를 여행하는 히치하이커를 위한 안내서에 언급된 "생명, 우주, 그리고 모든 것에 대한 궁극적인 질문에 대한 답"인 42를 참조하여 버전 4.2에서 시작했다.
 슬랙웨어 리눅스 배포판은 leet를 참조하여 버전 13.37로 지정되었다.
 핀닉스는 "Finnix '95는 없을 것이다"라는 주장을 부분적으로 이행하기 위해 버전 93.0에서 100으로 건너뛰었는데, 이는 윈도우 95를 참조한 것이다.
 태그 이미지 파일 형식 사양은 초기부터 42를 내부 버전 번호로 사용해왔는데, 설계자들은 개발 지침과 충돌할 것이므로 자신들의 생애(또는 파일 형식의 생애) 동안 더 이상 변경할 의도가 없었다.

 소프트웨어 예시 

 파이썬 
파이썬 소프트웨어 재단은 PEP 440 – 버전 식별 및 종속성 사양을 발표하여, 자체의 유연한 체계를 제시하고 있으며, 이는 에포크 세그먼트, 릴리스 세그먼트, 사전 릴리스 및 사후 릴리스 세그먼트, 개발 릴리스 세그먼트를 정의한다.

 TeX 
TeX은 개발자인 도널드 커누스가 고안한 특이한 버전 번호 매기기 시스템을 가지고 있다. 버전 3.1 이후로는 끝에 숫자를 하나 더 추가하여 업데이트를 나타내는데, 이는 버전 번호가 원주율에 점근적으로 접근하도록 하는 방식으로, 3.14는 시맨틱 버저닝에서 사실상 3.2를 의미한다. (이것은 일진법의 한 형태이다. 버전 번호는 자릿수이다.) 2021년 현재 버전 번호는 3.141592653이다. 이는 TeX이 매우 안정적이며, 사소한 업데이트만 예상된다는 것을 반영한다. TeX 개발자인 도널드 커누스는 "절대적으로 마지막 변경 사항([그의] 사망 후 이루어질)"은 버전 번호를 원주율로 바꾸는 것이며, 그 시점에서 남아있는 모든 버그는 영구적인 기능이 될 것이라고 말했다.

마찬가지로, 메타폰트의 버전 번호는 오일러 수, 에 점근적으로 접근한다. 2021년 2월 현재 버전 번호는 2.71828182이다. 메타폰트 역시 도널드 커누스가 TeX 조판 시스템의 동반자로 고안했다.

 애플 
클래식 맥 OS 시대에는 부 버전 번호가 ".1"을 거의 넘어가지 않았다. 넘어가는 경우에도 보통 바로 ".5"로 건너뛰어 릴리스가 "더 중요함"을 시사했다. 따라서 "8.5"는 "Mac OS 8과 반"을 나타내는 자체 릴리스로 마케팅되었고, 8.6은 사실상 "8.5.1"을 의미했다.

macOS X는 이러한 경향에서 벗어났는데, 이는 "X"(로마 숫자 10)가 제품 이름에 있었기 때문이다. 그 결과, OS X의 모든 버전은 숫자 10으로 시작했다. OS X의 첫 번째 주요 릴리스는 버전 번호 10.0이 부여되었지만, 다음 주요 릴리스는 11.0이 아니었다. 대신 10.1, 10.2, 10.3 등으로 각 후속 주요 릴리스에 번호가 매겨졌다. 따라서 OS X의 11번째 주요 버전은 "10.10"으로 명명되었다. macOS 10.12부터 이름에서 "X"가 삭제되었음에도 불구하고, 이 번호 매기기 체계는 macOS 10.15까지 계속되었다. "X" 기반 버전 관리 체계에서는 세 번째 숫자(두 번째 숫자 대신)가 부 릴리스를 나타냈고, 이 수준 아래의 추가 업데이트와 새로운 주요 버전 출시 후 특정 OS X 주요 버전에 대한 업데이트는 보충 업데이트(Supplemental Updates)로 명명되었다.

로마 숫자 X는 여러 제품 라인에서 마케팅 목적으로 동시에 활용되었다. 퀵타임과 파이널 컷 프로는 모두 버전 7에서 버전 10으로 건너뛰어 퀵타임 X와 파이널 컷 프로 X가 되었다. 맥 OS X 자체와 마찬가지로, 이 제품들은 이전 버전의 업그레이드가 아니라 완전히 새로운 프로그램이었다. OS X와 마찬가지로, 이 프로그램들의 주요 릴리스는 두 번째 숫자를 증가시켰고, 부 릴리스는 세 번째 숫자를 사용하여 나타냈다. macOS 11.0 출시(아래 참조)와 함께 파이널 컷 이름에서 "X"가 삭제되었고, 퀵타임의 브랜드는 2011년 AVFoundation이 선호되면서 프레임워크가 사용 중단됨에 따라 무의미해졌다(퀵타임 비디오 재생 프로그램은 처음부터 퀵타임 플레이어로만 불렸다).

애플의 다음 macOS 릴리스는 잠정적으로 10.16으로 번호가 매겨졌으며, 2020년 6월 WWDC에서 공식적으로 macOS 11로 발표되었고, 2020년 11월에 출시되었다. 다음 macOS 버전인 macOS 몬터레이는 2021년 10월에 출시되었고 주 버전 번호가 12로 올라갔다.

2025년 6월, Apple은 차량의 모델 연도와 유사하게 출시 날짜 옆에 연도를 사용하는 통합 버전 관리 체계를 발표했다. 2025년 가을에 출시된 버전은 iOS 26, macOS 26, iPadOS 26, tvOS 26, watchOS 26, visionOS 26이다.

 마이크로소프트 윈도우 
마이크로소프트 윈도우 운영 체제는 처음에는 윈도우 1.01부터 윈도우 3.2까지 표준 버전 번호로 레이블이 지정되었다. 이후 마이크로소프트는 제품 이름에서 버전 번호를 제외했다. 윈도우 95 (버전 4.0), 윈도우 98 (4.10), 윈도우 2000 (5.0)의 경우 출시 연도가 제품 제목에 포함되었다. 윈도우 2000 이후 마이크로소프트는 윈도우 서버 제품군을 만들었는데, 이는 연도 기반 스타일을 유지하면서 한 가지 차이점을 두었다. 즉, 사소한 릴리스의 경우 마이크로소프트는 제목에 "R2"를 접미사로 붙였다. 예를 들어, 윈도우 서버 2008 R2 (버전 6.1)와 같다. 이 스타일은 현재까지 일관되게 유지되었다. 그러나 윈도우의 클라이언트 버전은 일관된 스타일을 채택하지 않았다. 처음에는 윈도우 미 (4.90), 윈도우 XP (5.1), 윈도우 비스타 (6.0)와 같이 임의의 영숫자 접미사를 가진 이름이 부여되었다. 그런 다음 마이크로소프트는 다시 제목에 증분 숫자를 채택했지만, 이번에는 버전 번호가 아니었다. 윈도우 7, 윈도우 8, 윈도우 8.1의 버전 번호는 각각 6.1, 6.2, 6.3이다. 윈도우 10에서는 버전 번호가 10.0으로 건너뛰었고 OS에 대한 후속 업데이트는 빌드 번호(날짜 기반)와 업데이트 빌드 수정 (UBR) 번호만 증가시켰다.

윈도우 10의 후속 버전인 윈도우 11은 2021년 10월 5일에 출시되었다. "11"이라는 이름에도 불구하고, 새로운 윈도우 릴리스는 주 버전 번호를 11로 올리지 않았다. 대신 윈도우 10에서 사용된 것과 동일한 버전 번호인 10.0을 유지했다.

 소프트웨어 외 사용 
파일 시스템과 같은 일부 컴퓨터 파일 시스템(예: OpenVMS Filesystem)은 파일에 대한 버전도 유지한다. 문서 간의 버전 관리는 컴퓨터 및 소프트웨어 공학에서 사용되는 루틴과 비교적 유사하며, 구조, 내용 또는 조건의 작은 변경 사항이 있을 때마다 버전 번호가 1씩 또는 더 작거나 큰 값으로 증가하는데, 이는 작성자의 개인적인 선호도와 변경 사항의 크기 또는 중요도에 따라 달라진다.

기술 도면 및 CAD 소프트웨어 파일도 변경 사항을 추적하기 위해 일종의 원시 버전 번호를 사용할 수 있다.

 같이 보기 

 지속 데이터 보호
 유지보수 릴리스
 제품 수명 주기 관리
 릴리스 관리
 릴리스 노트
 소프트웨어 공학

 내용주 

 각주 

 외부 링크 
 리브레오피스 문서 재단 릴리스 계획, 릴리스 트레인 표시

분류:소프트웨어 버전 역사
분류:버전 관리