소프트웨어 버전 작성
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
소프트웨어 버전 작성은 소프트웨어의 릴리스를 식별하고 관리하는 체계에 대한 문서이다. 버전 관리는 1972년 MIT의 파일 시스템에서 처음 도입되었으며, 이후 PC 통신과 인터넷 발달로 중요성이 커졌다. 다양한 버전 넘버링 체계가 존재하며, 일반적으로 마침표로 구분된 숫자로 표현된다. 최초 정식 버전은 1.0으로 시작하며, 변경 정도에 따라 메이저, 마이너, 빌드 버전으로 구분한다. 시맨틱 버전(SemVer)은 주 버전, 부 버전, 패치 버전으로 구성되어 호환성을 나타낸다. 개발 단계는 알파, 베타, 릴리스 후보 등으로 분류되며, 개발 릴리스에 대한 홀수 버전, 가장 중요한 요소 삭제 등의 다양한 체계가 존재한다. 버전 번호는 소프트웨어의 식별 및 비교, 협업, 패치 및 업그레이드에 사용되며, 기술 지원, 파일 시스템, 영화, 앨범 등에서도 활용된다.
더 읽어볼만한 페이지
- 버전 관리 - 깃허브
깃허브는 Git 버전 관리 시스템을 기반으로 소프트웨어 개발 협업 기능과 부가 서비스를 제공하는 웹 기반 플랫폼이지만, 여러 논란과 비판도 존재하는 세계 최대의 소프트웨어 개발 플랫폼이다. - 버전 관리 - 스테핑 레벨
- 소프트웨어 공학 - 통합 개발 환경
통합 개발 환경(IDE)은 코드 편집, 빌드, 디버깅 등 소프트웨어 개발에 필요한 여러 기능을 통합적으로 제공하는 응용 프로그램이다. - 소프트웨어 공학 - 소프트웨어 개발
소프트웨어 개발은 요구사항 분석, 설계, 코딩, 테스트, 배포, 유지보수를 포함하는 컴퓨터 프로그램 및 관련 데이터를 만드는 과정으로, 다양한 방법론과 도구가 사용되며, 개발자 외에도 다양한 전문가들이 참여한다.
| 소프트웨어 버전 작성 | |
|---|---|
| 소프트웨어 버전 | |
| 유형 | 소프트웨어 식별자 |
| 목적 | 소프트웨어 릴리스의 고유 식별 버전 관리 |
| 형식 | 숫자 문자 점으로 구분된 숫자 날짜 |
| 관련 개념 | 소프트웨어 릴리스 수명 주기 의미론적 버전 관리 릴리스 트레인 지속적 릴리스 |
| 버전 번호 구성 요소 | |
| 주요 버전 | 중요한 기능 추가 및 아키텍처 변경을 나타냄 |
| 부 버전 | 주요 버전의 개선 사항 또는 작은 기능 추가를 나타냄 |
| 수정 버전 | 버그 수정 및 성능 개선을 나타냄 |
| 빌드 번호 | 특정 빌드를 식별하는 데 사용 |
| 릴리스 후보 | 최종 릴리스 전 테스트 버전 |
| 버전 관리 방법 | |
| 의미론적 버전 관리 (SemVer) | MAJOR.MINOR.PATCH 형식으로 버전 번호를 부여 |
| 날짜 기반 버전 관리 | 릴리스 날짜를 버전 번호에 포함 (예: YYYY.MM.DD) |
| 릴리스 트레인 | 정기적인 간격으로 새 버전을 릴리스 |
| 지속적 릴리스 | 변경 사항을 지속적으로 릴리스 |
| 일반적인 버전 문자열 예시 | |
| 예시 1 | 1.0.0 (SemVer) |
| 예시 2 | 2023.10.26 (날짜 기반 버전 관리) |
| 예시 3 | 1.2.3-rc1 (릴리스 후보) |
| 고려 사항 | |
| 호환성 | 이전 버전과의 호환성을 고려해야 함 |
| 명확성 | 버전 번호가 명확하고 이해하기 쉬워야 함 |
| 자동화 | 버전 관리 프로세스를 자동화할 수 있어야 함 |
2. 역사
파일 버전 관리 개념은 1972년 MIT의 ITS 파일 시스템에서 처음 도입되었으며, 이후 PDP-10용 TENEX 파일 시스템으로 이어졌다.[1] 데비안과 같이 dpkg를 사용하는 리눅스 배포판은 패키지 관리 소프트웨어를 통해 패키지 간의 종속성 문제를 해결하였다.[2][3][4] 1994년부터 패키지가 필요로 하는 패키지를 알게 되었고, 최소 패키지 버전이 도입되어 업그레이드가 용이하게 되었다.[2][3][4]
다양한 소프트웨어 버전 관리를 위해 여러 버전 넘버링 체계가 만들어졌다. 컴퓨터의 보급으로 인해 이러한 체계는 컴퓨팅 외의 다른 분야에서도 사용되고 있다. 일반적으로 컴퓨터용 소프트웨어는 한 번만 출시되는 것이 아니라, 지속적인 개선을 통해 여러 버전이 출시된다. 이러한 버전 간 차이를 명시하기 위해 '버전', '릴리스', '리비전' 등의 부가적인 명칭을 사용한다.[56][57]
한국에서는 1990년대 후반부터 PC 통신과 인터넷의 발달로 소프트웨어 배포 및 업데이트가 활발해지면서 버전 관리의 중요성이 부각되었다. 특히, 온라인 게임 산업의 급성장과 함께 잦은 업데이트와 패치가 이루어지면서 체계적인 버전 관리 시스템의 필요성이 커졌다.
3. 체계
버전 간 차이는 주로 피리어드로 구분된 숫자로 표현되며, 개선될수록 숫자가 커진다. 알파벳이 사용되기도 한다. 개선된 소프트웨어를 사용할 수 있게 만드는 것을 "버전 업"이라고 한다.
최초 정식 버전은 보통 "1.0"으로 시작하며, 변경 정도에 따라 큰 변경(메이저 버전)은 "2.0", 중간 변경(마이너 버전)은 "1.1", 작은 변경(빌드 또는 유지보수 버전)은 "1.0.1"과 같이 표현한다.[58][59][60] 상위 숫자가 증가하면 하위 숫자는 0으로 초기화된다(예: 1.2.3 → 1.3.0).
Windows OS와 마이크로소프트 구성 요소(Win32 DLL, 실행 프로그램, COM 구성 요소, .NET Framework어셈블리)는 빌드 번호가 초판부터 일련 번호로 관리되어, 메이저/마이너 버전 변경과 관계없이 계속 증가한다.[61] .NET Framework 어셈블리 개발에서는 메이저/마이너 번호 변경이 구성 요소 인터페이스호환성 손실을 의미한다.[62]
"1.0.0"처럼 피리어드가 2개 이상인 방식과 "1.00"처럼 단일 피리어드 방식이 있다. 전자는 소수점 표기와 모순된다는 의견도 있지만, "1.0.10"처럼 단일 실수 값으로 취급되지 않는 버전도 존재한다.
정식 제공 전 개발 단계(마일스톤)에서는 "알파 버전（α）", "베타 버전（β）", "릴리스 후보 버전（RC）" 등으로 분류하고, 각 단계의 리비전 번호를 붙여 "1.0.0a1"처럼 표기한다. 실험적 단계는 "0.8", "0.9"처럼 표기하기도 한다. 정식 제공 전 선행판은 "프리 릴리스"(Pre-release영어) 또는 "프릴리미너리"(Preliminary영어)라고도 한다.
기능이나 가격 차이에 따른 여러 파생 제품은 "버전" 대신 "에디션"(edition영어)이라고 부르기도 한다.[63]
3. 1. 차례열 기반 식별자
차례열 기반 식별자(Sequence-based identifiers)는 소프트웨어 버전 관리에 사용되는 방식이다. 각 소프트웨어 릴리스에는 숫자 또는 문자의 하나 이상의 시퀀스로 구성된 고유한 식별자가 할당된다.[5]
일반적으로 소프트웨어는 한 번 출시로 끝나는 것이 아니라, 결함 수정, 기능 추가/개선 등을 통해 지속적으로 개선되어 여러 버전이 출시된다. 이러한 버전 간 차이를 명시하고 유통 및 사용 단계에서의 혼란을 방지하기 위해 '버전', '릴리스', '리비전' 등의 부가적인 명칭을 사용한다.[56][57]
버전 간 차이는 주로 피리어드로 구분된 숫자의 나열로 표현되며, 개선이 진행될수록 숫자가 커진다. 알파벳이 사용되기도 한다. 개선된 소프트웨어를 사용할 수 있는 상태로 만드는 것을 "버전 업"이라고 한다.
최초 정식 버전은 보통 "1.0"으로 시작하며, 변경 정도에 따라 큰 변경(메이저 버전)은 "2.0", 중간 변경(마이너 버전)은 "1.1", 작은 변경(빌드 또는 유지보수 버전)은 "1.0.1"과 같이 표현한다.[58][59][60] 상위 숫자가 증가하면 하위 숫자는 0으로 초기화된다(예: 1.2.3 → 1.3.0).
Windows OS와 마이크로소프트 구성 요소(Win32 DLL, 실행 프로그램, COM 구성 요소, .NET Framework어셈블리)는 빌드 번호가 초판부터의 일련 번호로 관리되어, 메이저/마이너 버전 변경과 관계없이 계속 증가한다.[61] .NET Framework 어셈블리 개발에서는 메이저/마이너 번호 변경이 구성 요소 인터페이스호환성 손실을 의미하는 규칙이 있다.[62]
"1.0.0"처럼 피리어드가 2개 이상인 방식과 "1.00"처럼 단일 피리어드 방식이 있다. 전자는 소수점 표기와 모순된다는 의견도 있지만, "1.0.10"처럼 반드시 단일 실수 값으로 취급되지 않는 버전도 존재한다.
정식 제공 전 개발 단계(마일스톤)에서는 "알파 버전（α）", "베타 버전（β）", "릴리스 후보 버전（RC）" 등으로 분류하고, 각 단계의 리비전 번호를 붙여 "1.0.0a1"처럼 표기한다. 실험적 단계는 "0.8", "0.9"처럼 표기하기도 한다. 정식 제공 전 선행판은 "프리 릴리스"(Pre-release영어) 또는 "프릴리미너리"(Preliminary영어)라고도 한다.
기능이나 가격 차이에 따른 여러 파생 제품은 "버전" 대신 "에디션"(edition영어)이라고 부르기도 한다.[63]
== 변경과 중요성의 관계 ==
차례열 기반 식별자는 릴리스 간 변경의 중요성을 나타내기 위해 사용된다. 식별자 내 어떤 숫자/문자를 변경할지는 이전 버전 대비 변경의 중요성에 따라 결정된다. 첫 번째 숫자/문자는 가장 중요한 변경, 이후 순서는 중요도가 감소하는 변경을 의미한다.
버전 번호는 사람이 기입하므로 자의적 수정이 가능하며, 작성자 의도와 다른 인식을 심어줄 수 있다. 일반적으로 다음과 같은 형식이 사용된다.
major.minor[.build[.revision]]
혹은
major.minor[.maintenance[.build]]
변경 중요도는 코드 라인 수, 기능 점수, 사용자 영향, 버그/호환성 문제 위험, 시각적 레이아웃 변경, 새 기능 수, 마케팅적 요소 등 다양한 기준으로 평가될 수 있다.
한국에서는 온라인 게임의 잦은 업데이트와 패치로 인해 변경 중요도를 명확히 전달하는 버전 관리 체계가 중요하게 인식된다.
== 시맨틱 버전 ==
'''시맨틱 버전'''(SemVer)은 널리 사용되는 버전 관리 체계[7]로, 주 버전.부 버전.패치 버전, 선택적 사전 릴리스 태그, 선택적 빌드 메타 태그로 버전을 구성한다. 위험과 기능이 중요도 측정 척도이다. 호환성 깨지는 변경은 주 버전 증가(높은 위험), 호환성 유지 기능 추가는 부 버전 증가(중간 위험), 기타 호환성 유지 변경은 패치 버전 증가(낮은 위험)로 표시된다. 사전 릴리스 태그(-alpha, -beta)나 주 버전 0(0.y.z)은 높은 위험을 나타내며, 잠재적 호환성 문제를 포함하는 작업 진행 중임을 의미한다. API 버전 2.1.5에 의존하는 소프트웨어는 2.2.3과는 호환되지만 3.2.4와는 호환되지 않을 수 있다.[7]
개발자는 주 버전 증가에는 미치지 못하지만 중요한 기능 추가를 나타내기 위해 여러 부 버전 번호를 건너뛸 수 있다. (예: 인터넷 익스플로러 5 (5.1→5.5), 어도비 포토샵 (5→5.5)). 이는 업그레이드 가치를 강조하거나, 주 버전 사이 중간 릴리스를 나타내기 위함일 수 있다.
다른 접근 방식은 릴리스 유형을 나타내는 영숫자 문자열과 "주", "부" 번호를 함께 사용한다. (예: 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과 같이 진행될 수 있다. 이 체계에서는 릴리스 후보 단계에서 새 기능/호환성 깨는 변경을 차단하고, 베타 단계에서 버그 수정만 허용하여 안정화를 추구하는 것이 일반적이다.
다른 체계는 개별 시퀀스에 의미를 부여한다.
:''
:''
솔라리스 및 리눅스 공유 라이브러리는 ''
:''current'': 라이브러리가 구현하는 최신 인터페이스 번호.
:''revision'': 현재 인터페이스 구현 번호.
:''age'': 라이브러리가 구현하는 최신 및 가장 오래된 인터페이스 간 차이. (libtool에 특화)
상대적 변경 중요성과 버전 명칭 문제는 출판 분야의 판 번호 문제와 유사하다.
한국 소프트웨어 개발 환경에서도 시맨틱 버전 채택이 늘고 있으며, 오픈 소스 프로젝트와 API 개발에서 널리 사용된다.
== 호환성 정도 ==
일부 프로젝트는 메이저 버전 번호를 호환되지 않는 릴리스를 나타내는 데 사용한다.[10][11] 프로그래머는 새 소프트웨어를 하위 호환되도록 작성하는 경우가 많다. (이전 버전과 최신 버전 모두와 올바르게 상호 작용). IBM z/OS는 동일 sysplex에서 3개 연속 메이저 버전과 작동하도록 설계되었다.[12]
== 개발 단계 지정 ==
실험 단계 소프트웨어(알파, 베타)는 첫 번째("주요") 위치에 0을 사용하여 상태를 나타내기도 한다. 그러나 이는 초기 단계에만 유용하며, 이미 0을 넘은 기존 소프트웨어에는 부적합하다.[6]
새 릴리스 상태를 나타내는 방식은 다양하다.
| 개발 단계 | 시맨틱 버전 관리 | 숫자 상태 | 숫자 90+ |
|---|---|---|---|
| 알파 | 1.2.0-a.1 | 1.2.0.1 | 1.1.90 |
| 베타 | 1.2.0-b.2 | 1.2.1.2 | 1.1.93 |
| 릴리스 후보(RC) | 1.2.0-rc.3 | 1.2.2.3 | 1.1.97 |
| 릴리스 | 1.2.0 | 1.2.3.0 | 1.2.0 |
| 릴리스 후 수정 | 1.2.5 | 1.2.5.3 | 1.2.5 |
순수 숫자 형식은 시맨틱 버전 관리의 "알파 < 베타 < rc < 접두사 없음" 비교를 위한 특별 로직이 필요 없지만, 명확성은 떨어진다.
세 번째 자리에 0을 지정하거나 문자를 사용하여 알파, 베타 버전을 나타낼 수 있다.
- 0 - 알파 버전 (alpha)
- 1 - 베타 버전 (beta)
- 2 - 발매 버전 후보 (release candidate)
- 3 - 발매 버전 (final release)
예시:
- 1.2.0.1 <- 1.2-a1에서 수정
- 1.2.1.2 <- 1.2-b2에서 수정 (약간 버그 수정하여 베타 버전으로 업그레이드)
- 1.2.2.3 <- 1.2-rc3 (발매 버전 후보)
- 1.2.3.0 <- 1.2-r (상업용 배포판)
- 1.2.3.5 <- 1.2-r5 (많은 버그를 수정한 상업용 배포판)
정식 제공 전 개발 단계(마일스톤)에서는 "알파 버전（α）", "베타 버전（β）", "릴리스 후보 버전（RC）" 등으로 분류하고, 각 단계의 리비전 번호를 붙여 "1.0.0a1"처럼 표기한다. 실험적 단계는 "0.8", "0.9"처럼 표기하기도 한다. 정식 제공 전 선행판은 "프리 릴리스"(Pre-release영어) 또는 "프릴리미너리"(Preliminary영어)라고도 한다.
한국에서는 모바일 게임 개발의 빠른 개발 주기와 잦은 업데이트로 인해 개발 단계를 명확히 표시하는 버전 관리 방식이 중요하게 활용된다.
== 시퀀스 증가 ==
소프트웨어 버전 번호 증가 방식에 대한 두 가지 견해가 있다. 미디어위키를 포함한 대부분의 자유 및 오픈 소스 소프트웨어는 버전을 점으로 구분된 개별 숫자로 취급한다(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년대에 넷웨어(NetWare), DOS, 마이크로소프트 윈도우(Microsoft Windows)에서 사용되었고, 2000년대에도 오페라(Opera)[13] 및 무버블 타입(Movable Type)[14]에서 사용되었다. 소수점 방식에서 1.81은 1.8 다음 마이너 버전이며, 유지 관리 릴리스(버그 수정)는 1.81a, 1.81b와 같이 알파벳 접미사로 표시될 수 있다.
표준 GNU 버전 번호 체계는 major.minor.revision[15]이지만, 이맥스(Emacs)는 예외적으로 주 번호(1)를 삭제하고 사용자 사이트 개정 번호를 추가하는 다른 체계를 사용한다.[18] 데비안(Debian) 패키지 번호는 선택적 "epoch"로 시작하여 버전 관리 체계 변경을 허용한다.[16]
일반적으로 소프트웨어는 한 번 출시로 끝나는 것이 아니라, 결함 수정, 기능 추가/개선 등을 통해 지속적으로 개선되어 여러 버전이 출시된다. 이러한 버전 간 차이를 명시하고 유통 및 사용 단계에서의 혼란을 방지하기 위해 '버전', '릴리스', '리비전' 등의 부가적인 명칭을 사용한다.[56][57]
버전 간 차이는 주로 피리어드로 구분된 숫자의 나열로 표현되며, 개선이 진행될수록 숫자가 커진다. 알파벳이 사용되기도 한다. 개선된 소프트웨어를 사용할 수 있는 상태로 만드는 것을 "버전 업"이라고 한다.
최초 정식 버전은 보통 "1.0"으로 시작하며, 변경 정도에 따라 큰 변경(메이저 버전)은 "2.0", 중간 변경(마이너 버전)은 "1.1", 작은 변경(빌드 또는 유지보수 버전)은 "1.0.1"과 같이 표현한다.[58][59][60] 상위 숫자가 증가하면 하위 숫자는 0으로 초기화된다(예: 1.2.3 → 1.3.0).
Windows OS와 마이크로소프트 구성 요소(Win32 DLL, 실행 프로그램, COM 구성 요소, .NET Framework어셈블리)는 빌드 번호가 초판부터의 일련 번호로 관리되어, 메이저/마이너 버전 변경과 관계없이 계속 증가한다.[61] .NET Framework 어셈블리 개발에서는 메이저/마이너 번호 변경이 구성 요소 인터페이스호환성 손실을 의미하는 규칙이 있다.[62]
"1.0.0"처럼 피리어드가 2개 이상인 방식과 "1.00"처럼 단일 피리어드 방식이 있다. 전자는 소수점 표기와 모순된다는 의견도 있지만, "1.0.10"처럼 반드시 단일 실수 값으로 취급되지 않는 버전도 존재한다.
정식 제공 전 개발 단계(마일스톤)에서는 "알파 버전（α）", "베타 버전（β）", "릴리스 후보 버전（RC）" 등으로 분류하고, 각 단계의 리비전 번호를 붙여 "1.0.0a1"처럼 표기한다. 실험적 단계는 "0.8", "0.9"처럼 표기하기도 한다. 정식 제공 전 선행판은 "프리 릴리스"(Pre-release영어) 또는 "프릴리미너리"(Preliminary영어)라고도 한다.
== 리셋 ==
개발자가 주요 버전 번호를 재설정하여 새로운 개발 단계 출시를 나타내기도 한다. 예: ''마인크래프트''(Minecraft) 알파 버전(1.0.0~1.2.6), 베타 버전 출시 후 주요 버전 재설정(1.0~1.8), 정식 출시 후 다시 재설정(1.0.0).[17]
== 시퀀스 분리 ==
인쇄 시 시퀀스는 문자로 구분될 수 있으며, 문자 선택/사용법은 스킴에 따라 다르다. 동일 릴리스(2단계 개정 4번째, 2단계 개정 13번째 3단계 개정)에 대한 가상 구분 예시:
- 모든 시퀀스 사이에 동일 문자: 2.4.13, 2/4/13, 2-4-13
- 일부 시퀀스만 구분: 2.413
- 동일 식별자 내 일관성 없는 문자: 2.4_13 (''마인크래프트'' 베타: 1.7 → 1.7_01 → 1.7.2)
피리어드로 시퀀스 구분 시, "시퀀스 증가" 섹션의 다양한 해석 스타일 참고.
== 시퀀스 수 ==
공개되지 않은 네 번째 숫자가 소프트웨어 빌드를 나타내기도 한다(예: 마이크로소프트).[61] 어도비 플래시는 4부분 버전 번호(10.1.53.64)를 공개적으로 표시한다. 빌드 날짜를 포함하는 회사도 있다. 버전 번호는 로터스 1-2-3 릴리스 1a처럼 문자 등을 포함할 수 있다.
일반적으로 소프트웨어는 한 번 출시로 끝나는 것이 아니라, 결함 수정, 기능 추가/개선 등을 통해 지속적으로 개선되어 여러 버전이 출시된다. 이러한 버전 간 차이를 명시하고 유통 및 사용 단계에서의 혼란을 방지하기 위해 '버전', '릴리스', '리비전' 등의 부가적인 명칭을 사용한다.[56][57]
버전 간 차이는 주로 피리어드로 구분된 숫자의 나열로 표현되며, 개선이 진행될수록 숫자가 커진다. 알파벳이 사용되기도 한다. 개선된 소프트웨어를 사용할 수 있는 상태로 만드는 것을 "버전 업"이라고 한다.
최초 정식 버전은 보통 "1.0"으로 시작하며, 변경 정도에 따라 큰 변경(메이저 버전)은 "2.0", 중간 변경(마이너 버전)은 "1.1", 작은 변경(빌드 또는 유지보수 버전)은 "1.0.1"과 같이 표현한다.[58][59][60] 상위 숫자가 증가하면 하위 숫자는 0으로 초기화된다(예: 1.2.3 → 1.3.0).
하지만 Windows OS와 마이크로소프트 구성 요소(Win32 DLL, 실행 프로그램, COM 구성 요소, .NET Framework어셈블리)는 빌드 번호가 초판부터의 일련 번호로 관리되어, 메이저/마이너 버전 변경과 관계없이 계속 증가한다.[61] .NET Framework 어셈블리 개발에서는 메이저/마이너 번호 변경이 구성 요소 인터페이스호환성 손실을 의미하는 규칙이 있다.[62]
"1.0.0"처럼 피리어드가 2개 이상인 방식과 "1.00"처럼 단일 피리어드 방식이 있다. 전자는 소수점 표기와 모순된다는 의견도 있지만, "1.0.10"처럼 반드시 단일 실수 값으로 취급되지 않는 버전도 존재한다.
== 음수 ==
일부 프로젝트는 음수 버전 번호를 사용한다. 예: 스마트이펠(SmartEiffel) 컴파일러(-1.0에서 시작하여 0.0까지 증가).[18]
3. 1. 1. 변경과 중요성의 관계
차례열 기반 식별자는 배포판들 간의 변경의 중요성을 알리기 위한 목적으로 사용한다. 이는 식별자들 중, 어느 위치의 문자나 숫자를 변화할 것이냐의 결정은 이전 버전과에서 변경된 정도의 중요성에 따라 결정함으로써 이루어진다. 첫 번째 문자나 숫자가 수정될 수록 가장 중요한 수정이 가해졌다는 의미이며, 다음 순서로 넘어갈 수록 좀 더 그 의미가 줄어들게 된다.
버전 번호가 컴퓨터가 아니라 사람에 의해 기입되는만큼, 자의적인 수정을 막을 수 있는 방법은 없다. 어느 위치의 번호를 조작하느냐에 따라 경우에 따라 작성자의 의도와 달리 잘못된 인식을 심어줄 수도 있다. 일반적으로는 다음과 같은 순서로 이루어진다.
major.minor[.build[.revision]]
혹은
major.minor[.maintenance[.build]]
일부 방식에서는 릴리스 간의 변경 사항의 중요성을 전달하기 위해 시퀀스 기반 식별자를 사용한다. 변경 사항은 중요도 수준별로 분류되며, 릴리스 간에 어떤 시퀀스를 변경할 것인지에 대한 결정은 이전 릴리스의 변경 사항 중요도에 따라 이루어진다. 여기서 첫 번째 시퀀스는 가장 중요한 변경 사항에 대해 변경되고, 첫 번째 시퀀스 이후의 변경 사항은 중요도가 감소하는 변경 사항을 나타낸다.
방식에 따라 변경 사항의 중요도는 변경된 코드 라인 수, 추가되거나 제거된 기능 점수, 새 버전을 채택하는 데 필요한 작업 측면에서 고객에게 미칠 수 있는 잠재적 영향, 버그 또는 선언되지 않은 호환성 파괴 변경의 위험, 시각적 레이아웃의 변경 정도, 새로운 기능의 수 또는 제품 개발자나 마케터가 중요하다고 간주하는 거의 모든 것에 의해 평가될 수 있다. 여기에는 새 버전의 "상대적 우수성"을 강조하려는 마케팅 욕구도 포함된다.
한국에서는 특히 온라인 게임에서 잦은 업데이트와 패치가 이루어지면서, 변경 사항의 중요도를 명확하게 전달하는 버전 관리 체계가 중요하게 인식되고 있다.
3. 1. 2. 시맨틱 버전
'''시맨틱 버전'''(SemVer)은 널리 채택된 버전 관리 체계[7]로, 주 버전.부 버전.패치 버전, 선택적 사전 릴리스 태그, 선택적 빌드 메타 태그로 버전을 인코딩한다. 이 체계에서 위험과 기능은 중요성을 측정하는 척도이다. 호환성이 깨지는 변경 사항은 주 버전 번호 증가(높은 위험)로 표시되고, 새로운 호환성을 유지하는 기능은 부 버전 번호 증가(중간 위험)로 표시되며, 호환성을 유지하는 다른 모든 변경 사항은 패치 버전 번호 증가(가장 낮은 위험)로 표시된다. 사전 릴리스 태그(-alpha, -beta)의 존재는 주 버전 번호가 0(0.y.z)인 경우와 마찬가지로 상당한 위험을 나타낸다. 이는 잠재적으로 호환성이 깨지는 모든 수준의 변경 사항을 포함할 수 있는 작업 진행 중임을 나타내는 데 사용된다(가장 높은 위험). SemVer 버전에서 호환성을 추론하는 예로, API 버전 2.1.5에 의존하는 소프트웨어는 버전 2.2.3과 호환되지만 3.2.4와 반드시 호환되는 것은 아니다.[7]
개발자는 주 버전 번호를 증가시킬 만큼 충분하지 않지만 중요한 기능이 추가되었음을 나타내기 위해 여러 개의 부 버전 번호를 한 번에 건너뛸 수 있다. 예를 들어, 인터넷 익스플로러 5의 경우 5.1에서 5.5로, 어도비 포토샵의 경우 5에서 5.5로 버전이 변경되었다. 이는 소프트웨어 사용자에 대한 업그레이드의 가치를 강조하기 위해 수행될 수 있거나, 어도비의 경우와 같이 주 버전 사이의 중간 릴리스를 나타내기 위해 수행될 수 있다.
다른 접근 방식은 릴리스 유형을 나타내는 영숫자 문자열과 함께 "주" 및 "부" 번호를 사용하는 것이다. 예를 들어 "alpha"(a), "beta"(b) 또는 "릴리스 후보"(rc)가 있다. 이 접근 방식을 사용하는 소프트웨어 릴리스 트레인은 0.5, 0.6, 0.7, 0.8, 0.9 → 1.0b1, 1.0b2(일부 수정 사항 포함), 1.0b3(더 많은 수정 사항 포함) → 1.0rc1(충분히 안정적인 경우), 1.0rc2(더 많은 버그가 발견된 경우) → 1.0과 같이 보일 수 있다. 이 체계에서는 릴리스 후보 단계 동안 새로운 기능과 호환성이 깨지는 변경 사항을 차단하고, 일부 팀의 경우 베타 단계에서도 버그 수정만 허용하여 목표 릴리스로의 수렴을 보장하는 것이 일반적인 관행이다.
다른 체계는 개별 시퀀스에 의미를 부여한다.
:''
:''
솔라리스 및 리눅스의 공유 라이브러리는 다음과 같은 ''
:''current'': 라이브러리가 구현하는 가장 최근의 인터페이스 번호이다.
:''revision'': 현재 인터페이스의 구현 번호이다.
:''age'': 라이브러리가 구현하는 최신 및 가장 오래된 인터페이스 간의 차이이다. 세 번째 필드를 사용하는 것은 libtool에 특정하며, 다른 사용자는 다른 의미를 사용하거나 단순히 무시할 수 있다.
상대적인 변경의 중요성과 버전 관리 명칭에 대한 유사한 문제는 판 번호 또는 이름이 다양한 기준에 따라 선택될 수 있는 출판 분야에도 존재한다.
최초의 정식 제공에서는 먼저 "1.0"이라는 버전 번호가 부여되며, 다음 개량판에서는, 그 개변된 정도의 차이에 따라 큰 변경 시 (메이저 버전)에는 "'''2'''.0"으로 하거나, 중간 정도 (마이너 버전)에서는 "1.'''1'''"로 하며, 결함 수정 등 작은 변경 (빌드 또는 유지 보수 버전)에서는 "1.0.'''1'''"과 같은 식으로 표현하는 것이 일반적이다[58][59][60]。또한 상위 숫자가 더해지면 하위 숫자는 0으로 되돌아간다 (예: 1.2.3 → 1.'''3.0'''）。
정식 제공 전의 개발 도중에는, 진행 단계 (마일스톤)에 따라 "알파 버전（α）", "베타 버전（β）", "릴리스 후보 버전（RC）"으로 분류되며, 각 단계에서의 리비전 번호를 붙여 "1.0.0a1"과 같이 표기하는 것이 일반적이다. 사양 자체가 미정인 실험적인 단계에서는 "0.8" 또는 "0.9"와 같은 버전 번호가 부여되는 경우도 있다. 정식 제공 전의 선행판은 "프리 릴리스"(Pre-release영어) 또는 잠정판을 나타내는 "프릴리미너리"(Preliminary영어)라고도 불린다.
한국의 소프트웨어 개발 환경에서도 시맨틱 버전을 채택하는 사례가 늘고 있으며, 특히 오픈 소스 프로젝트와 API 개발에서 널리 사용되고 있다.
3. 1. 3. 호환성 정도
일부 프로젝트에서는 호환되지 않는 릴리스를 나타내기 위해 메이저 버전 번호를 사용한다.[10][11] 프로그래머는 종종 새로운 소프트웨어를 하위 호환되도록 작성한다. 즉, 새 소프트웨어는 이전 버전의 소프트웨어(이전 프로토콜 및 파일 형식 사용) 및 최신 버전(최신 프로토콜 및 파일 형식 사용)과 올바르게 상호 작용하도록 설계되었다. 예를 들어, IBM z/OS는 동일한 sysplex에서 실행되는 운영 체제의 3개의 연속적인 메이저 버전과 제대로 작동하도록 설계되었다.[12]3. 1. 4. 개발 단계 지정
실험 단계의 소프트웨어 (알파 또는 베타)는 상태를 나타내기 위해 시퀀스의 첫 번째("주요") 위치에 0을 사용하는 경우가 많다. 그러나 이 방식은 초기 단계에만 유용하며, 버전 번호가 이미 0을 넘어 진행된 기존 소프트웨어의 출시 예정 버전에 대해서는 유용하지 않다.[6]새로운 릴리스의 상태를 나타내기 위해 여러 가지 방식이 사용된다.
- ''영숫자 접미사''는 시맨틱 버전 관리에서 채택하는 일반적인 방식이다.[6] 이 방식에서 버전은 상태를 나타내기 위해 대시와 몇몇 영숫자 문자를 접미사로 사용한다.
- ''숫자 상태''는 숫자를 시퀀스의 일부인 것처럼 사용하여 상태를 나타내는 방식이다. 일반적인 선택은 4자리 버전 관리의 세 번째 위치이다.
- ''숫자 90+''는 숫자를 사용하지만, 이전 버전의 번호 아래에 있는 또 다른 방식이다. 마지막 위치에는 일반적으로 90 이상인 큰 숫자가 사용된다. 이는 폰트config와 같은 오래된 오픈 소스 프로젝트에서 일반적으로 사용된다.
| 개발 단계 | 시맨틱 버전 관리 | 숫자 상태 | 숫자 90+ |
|---|---|---|---|
| 알파 | 1.2.0-a.1 | 1.2.0.1 | 1.1.90 |
| 베타 | 1.2.0-b.2 | 1.2.1.2 | 1.1.93 |
| 릴리스 후보(RC) | 1.2.0-rc.3 | 1.2.2.3 | 1.1.97 |
| 릴리스 | 1.2.0 | 1.2.3.0 | 1.2.0 |
| 릴리스 후 수정 | 1.2.5 | 1.2.5.3 | 1.2.5 |
두 개의 순수 숫자 형태는 시맨틱 버전 관리에서 발견되는 "알파 < 베타 < rc < 접두사 없음"의 비교를 처리하는 데 필요한 특별한 로직을 제거하지만, 명확성은 희생된다.
세번째 자리수가 숫자를 0으로 지정하여 아직 배포하기엔 불충분한 수준 (알파, 베타 버전)을 나타낼 수 있다. 또는 간혹 문자로 표기될수있다. 이는 테스트용 혹은 개발용으로만 사용할 수 있음을 나타낸다.
아래와 같이 세 번째 위치에 사용할 수 있다.
- 0 - 알파 버전 (alpha)
- 1 - 베타 버전 (beta)
- 2 - 발매 버전 후보 (release candidate)
- 3 - 발매 버전 (final release)
예를 들면 아래와 같다.
- 1.2.0.1 <- 1.2-a1에서 수정
- 1.2.1.2 <- 1.2-b2에서 수정 (약간 버그 수정하여 베타 버전으로 업그레이드)
- 1.2.2.3 <- 1.2-rc3 (발매 버전 후보)
- 1.2.3.0 <- 1.2-r (상업용 배포판)
- 1.2.3.5 <- 1.2-r5 (많은 버그를 수정한 상업용 배포판)
정식 제공 전의 개발 도중에는, 진행 단계 (마일스톤)에 따라 "알파 버전（α）", "베타 버전（β）", "릴리스 후보 버전（RC）"으로 분류되며, 각 단계에서의 리비전 번호를 붙여 "1.0.0a1"과 같이 표기하는 것이 일반적이다. 사양 자체가 미정인 실험적인 단계에서는 "0.8" 또는 "0.9"와 같은 버전 번호가 부여되는 경우도 있다. 정식 제공 전의 선행판은 "프리 릴리스"(Pre-release영어) 또는 잠정판을 나타내는 "프릴리미너리"(Preliminary영어)라고도 불린다.
한국에서는 특히 모바일 게임 개발에서 빠른 개발 주기와 잦은 업데이트가 이루어지면서, 개발 단계를 명확하게 표시하는 버전 관리 방식이 중요하게 활용되고 있다.
3. 1. 5. 시퀀스 증가
소프트웨어 버전 번호를 증가시키는 방법에는 두 가지 견해가 있다. 미디어위키를 포함한 대부분의 자유 및 오픈 소스 소프트웨어 패키지는 버전을 점으로 구분된 일련의 개별 숫자로 취급하며, 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년대에 흔히 사용되었으며, 예를 들어 넷웨어(NetWare), DOS, 마이크로소프트 윈도우(Microsoft Windows)에서 사용되었지만, 2000년대에도 오페라(Opera)[13] 및 무버블 타입(Movable Type)에서 사용되었다.[14] 소수점 방식에서 1.81은 1.8 다음의 마이너 버전이며, 유지 관리 릴리스(즉, 버그 수정만)는 1.81a 또는 1.81b와 같은 알파벳 접미사로 표시될 수 있다.
표준 GNU 버전 번호 매기기 체계는 major.minor.revision[15]이지만, 이맥스(Emacs)는 주요 숫자(1)가 삭제되고 배포자에 의해 증가하지만 원래 Emacs 패키지에서는 항상 0인 ''사용자 사이트'' 개정 번호가 추가되는 다른 체계를 사용하는 주목할 만한 예이다.[18] 마찬가지로, 데비안(Debian) 패키지 번호는 버전 관리 체계를 변경할 수 있도록 하는 선택적 "epoch"로 시작한다.[16]
일반적으로 컴퓨터용 소프트웨어는 단일 제품을 한 번만 출시하고 종료하는 경우는 비교적 적고, 최초 출시 제품에 포함된 결함을 제거하거나, 새로운 기능을 추가하거나, 기존 기능을 개선하는 등, 매번 이전과는 다른 버전의 제품을 출시하는 경우가 자주 있다. 이러한 시계열적인 차이를 명시함으로써, 유통 및 사용 단계에서의 혼란을 피하기 위해, 주된 제품명에 '''버전''' 또는 '''릴리스''' , '''리비전'''이라는 형태로 부가적인 명칭을 추가한다[56][57]。
버전 간의 차이는 피리어드 기호로 구분된 숫자의 나열로 표현되는 것이 일반적이며, 개선이 진행됨에 따라 이러한 수치가 커진다. 숫자에 더해 알파벳이 사용되는 경우도 있다. 발전된 버전의 소프트웨어를 컴퓨터상에서 사용할 수 있는 상태로 만드는 것을 "버전 업"이라고 부른다.
최초의 정식 제공에서는 먼저 "1.0"이라는 버전 번호가 부여되며, 다음 개량판에서는, 그 개변된 정도의 차이에 따라 큰 변경 시 (메이저 버전)에는 "'''2'''.0"으로 하거나, 중간 정도 (마이너 버전)에서는 "1.'''1'''"로 하며, 결함 수정 등 작은 변경 (빌드 또는 유지 보수 버전)에서는 "1.0.'''1'''"과 같은 식으로 표현하는 것이 일반적이다[58][59][60]。또한 상위 숫자가 더해지면 하위 숫자는 0으로 되돌아간다 (예: 1.2.3 → 1.'''3.0'''）。
Windows OS 본체 및 부속하는 마이크로소프트 제 구성 요소 (Win32 DLL, 실행 프로그램, COM 구성 요소, 및 .NET Framework어셈블리)와 같이, 빌드 번호는 초판부터의 일련 번호가 되어 있으며, 메이저 번호나 마이너 번호가 변경되어도 리셋되지 않고 지속적으로 증가하는 관리 방식도 있다[61]。.NET Framework 어셈블리 개발에서는, 전형적인 예로 메이저 번호, 마이너 번호에 변경이 있었을 경우, 구성 요소의 인터페이스호환성이 손실되었음을 의미하는 규칙이 제시되어 있다[62]。
표기법은 "1.0.0"과 같이 피리어드가 2개 이상 있는 방식과 "1.00"과 같이 피리어드가 단일인 방식이 있으며, 전자의 경우 피리어드가 복수이므로 일반적인 소수점 표기와 모순이 있어 의문을 제기하는 경우가 있지만, 소프트웨어에 따라 "1.0.10" 등의 버전 번호도 존재하며, 반드시 단일 실수 값처럼 취급되지는 않는다.
정식 제공 전의 개발 도중에는, 진행 단계 (마일스톤)에 따라 "알파 버전（α）", "베타 버전（β）", "릴리스 후보 버전（RC）"으로 분류되며, 각 단계에서의 리비전 번호를 붙여 "1.0.0a1"과 같이 표기하는 것이 일반적이다. 사양 자체가 미정인 실험적인 단계에서는 "0.8" 또는 "0.9"와 같은 버전 번호가 부여되는 경우도 있다. 정식 제공 전의 선행판은 "프리 릴리스"(Pre-release영어) 또는 잠정판을 나타내는 "프릴리미너리"(Preliminary영어)라고도 불린다.
3. 1. 6. 리셋
경우에 따라 개발자는 주요 버전 번호를 재설정하여 새로운 개발 단계의 출시를 나타내기도 한다. 예를 들어, ''마인크래프트''(Minecraft) 알파 버전은 1.0.0에서 1.2.6까지 실행되었으며, 베타 버전이 출시되었을 때 주요 버전 번호가 재설정되어 1.0에서 1.8까지 실행되었다. 게임이 완전히 출시되면 주요 버전 번호가 다시 1.0.0으로 재설정되었다.[17]3. 1. 7. 시퀀스 분리
인쇄 시, 시퀀스는 문자로 구분될 수 있으며, 문자 선택과 사용법은 스킴에 따라 다르다. 다음은 동일한 릴리스(두 번째 레벨 개정판의 네 번째 두 번째 레벨 개정판에 대한 열세 번째 세 번째 레벨 개정)에 대한 가상 구분 스킴의 예시다.- 스킴은 모든 시퀀스 사이에 동일한 문자를 사용할 수 있다: 2.4.13, 2/4/13, 2-4-13
- 스킴은 일부 시퀀스를 구분하지만 다른 시퀀스는 구분하지 않는 등, 어떤 시퀀스를 구분할지 선택하는 것이 일관되지 않을 수 있다: 2.413
- 스킴의 문자 선택은 동일한 식별자 내에서 일관되지 않을 수 있다: 2.4_13 (예를 들어, ''마인크래프트'' 베타는 1.7에서 1.7_01, 1.7.2로 증가했다)
피리어드를 사용하여 시퀀스를 구분하는 경우, "시퀀스 증가" 섹션에서 다양한 해석 스타일을 참조하여, 소수점을 나타낼 수도 있고 나타내지 않을 수도 있다.
3. 1. 8. 시퀀스 수
때로는 공개되지 않은 네 번째 숫자가 소프트웨어 빌드를 나타내기도 한다(예: 마이크로소프트).[61] 어도비 플래시는 10.1.53.64와 같이 4부분으로 된 버전 번호가 공개적으로 표시되는 대표적인 경우이다. 일부 회사에서는 빌드 날짜를 포함하기도 한다. 버전 번호는 또한 로터스 1-2-3 릴리스 1a와 같이 문자 및 기타 문자를 포함할 수 있다.일반적으로 컴퓨터용 소프트웨어는 최초 출시 제품에 포함된 결함을 제거하거나, 새로운 기능을 추가하거나, 기존 기능을 개선하는 등, 매번 이전과는 다른 버전의 제품을 출시하는 경우가 자주 있다. 이러한 시계열적인 차이를 명시함으로써 유통 및 사용 단계에서의 혼란을 피하기 위해 주된 제품명에 '''버전''' 또는 '''릴리스''', '''리비전'''이라는 형태로 부가적인 명칭을 추가한다.[56][57]
버전 간의 차이는 피리어드 기호로 구분된 숫자의 나열로 표현되는 것이 일반적이며, 개선이 진행됨에 따라 이러한 수치가 커진다. 숫자에 더해 알파벳이 사용되는 경우도 있다. 발전된 버전의 소프트웨어를 컴퓨터상에서 사용할 수 있는 상태로 만드는 것을 "버전 업"이라고 부른다.
최초의 정식 제공에서는 먼저 "1.0"이라는 버전 번호가 부여되며, 다음 개량판에서는, 그 개변된 정도의 차이에 따라 큰 변경 시 (메이저 버전)에는 "'''2'''.0"으로 하거나, 중간 정도 (마이너 버전)에서는 "1.'''1'''"로 하며, 결함 수정 등 작은 변경 (빌드 또는 유지 보수 버전)에서는 "1.0.'''1'''"과 같은 식으로 표현하는 것이 일반적이다.[58][59][60] 또한 상위 숫자가 더해지면 하위 숫자는 0으로 되돌아간다 (예: 1.2.3 → 1.'''3.0''').
하지만 Windows OS 본체 및 부속하는 마이크로소프트 제 구성 요소 (Win32 DLL, 실행 프로그램, COM 구성 요소, 및 .NET Framework어셈블리)와 같이, 빌드 번호는 초판부터의 일련 번호가 되어 있으며, 메이저 번호나 마이너 번호가 변경되어도 리셋되지 않고 지속적으로 증가하는 관리 방식도 있다.[61] .NET Framework 어셈블리 개발에서는, 전형적인 예로 메이저 번호, 마이너 번호에 변경이 있었을 경우, 구성 요소의 인터페이스호환성이 손실되었음을 의미하는 규칙이 제시되어 있다.[62]
표기법은 "1.0.0"과 같이 피리어드가 2개 이상 있는 방식과 "1.00"과 같이 피리어드가 단일인 방식이 있으며, 전자의 경우 피리어드가 복수이므로 일반적인 소수점 표기와 모순이 있어 의문을 제기하는 경우가 있지만, 소프트웨어에 따라 "1.0.10" 등의 버전 번호도 존재하며, 반드시 단일 실수 값처럼 취급되지는 않는다.
3. 1. 9. 음수
일부 프로젝트는 음수 버전 번호를 사용한다. 한 가지 예는 −1.0에서 시작하여 0.0까지 증가한 스마트이펠(SmartEiffel) 컴파일러이다.[18]3. 2. 릴리스 날짜
많은 프로젝트에서 날짜 기반 버전 관리 체계인 캘린더 버전 관리(CalVer)를 사용한다.[19] 우분투는 캘린더 버전 관리를 사용하는 프로젝트의 한 예시이다. 우분투 18.04는 2018년 4월에 출시되었다. 이는 개발 일정 및 지원 기간과 쉽게 관련지을 수 있다는 장점이 있다.
아케이드 게임 ''스트리트 파이터 EX''와 같은 일부 비디오 게임에서도 버전 관리에 날짜를 사용하는데, 시작 시 버전 번호를 날짜와 지역 코드로 표시한다. 예를 들어 ''961219 ASIA''와 같다.
버전 관리에 날짜를 사용할 때는 ISO 8601 체계[20]인 ''YYYY-MM-DD''를 사용하는 것이 일반적인데, 문자열 정렬 시 오름차순 또는 내림차순으로 쉽게 정렬할 수 있기 때문이다. 하이픈은 생략되기도 한다. Wine 프로젝트는 이전에 출시 연도, 월, 일 순으로 날짜 버전 관리 체계를 사용했다. 예를 들어 "Wine 20040505"와 같다. ''마인크래프트''도 이와 유사한 버전 형식을 사용했지만, 대신 DDHHMM 형식을 사용했다. 예를 들어 rd-132211에서 13은 5월 13일, 2211은 22:11을 의미한다.
마이크로소프트 오피스 빌드 번호는 인코딩된 날짜이다.[21] 처음 두 자리는 프로젝트가 시작된 해의 1월부터 경과한 개월 수를 나타내고(각 주요 오피스 릴리스는 서로 다른 프로젝트), 마지막 두 자리는 해당 월의 날짜를 나타낸다. 따라서 3419는 프로젝트가 시작된 해의 1월부터 34개월이 지난 달의 19일이다.
년도로 버전을 식별하는 다른 예시로는 어도비 일러스트레이터 88과 워드퍼펙트 오피스 2003이 있다. 년도를 버전으로 사용하는 경우, 일반적으로 마케팅 목적으로 사용되며 실제 버전 번호도 존재한다. 예를 들어, 윈도우 95는 내부적으로 MS-DOS 7.00 및 윈도우 4.00으로 버전이 관리되고, 윈도우 2000은 내부적으로 NT 5.0으로 버전이 관리된다.[22]
한국에서는 연도, 월, 일 등을 조합한 날짜 기반 버전 관리 체계가 널리 사용되며, 특히 정부 및 공공기관의 소프트웨어 프로젝트에서 자주 활용된다.
4. 소프트웨어 예시
4. 1. 파이썬
파이썬 소프트웨어 재단은 PEP 440을 발표하여 에포크 세그먼트, 릴리스 세그먼트, 사전 릴리스 및 사후 릴리스 세그먼트, 개발 릴리스 세그먼트를 정의하는 자체적인 유연한 버전 관리 스킴을 설명했다.[23]4. 2. TeX
TeX는 개발자 도널드 커누스가 발명한 특이한 버전 넘버링 시스템을 가지고 있다.[24] 버전 3.1 이후, 업데이트는 끝에 추가적인 숫자를 더하여 표시되었으며, 버전 번호는 점근적으로 π에 접근한다.[24] 2021년 2월 기준으로, 버전 번호는 3.141592653이다.[24] 이는 TeX가 매우 안정적이며, 사소한 업데이트만 예상된다는 것을 반영한다. TeX 개발자 도널드 커누스는 ''"절대 최종 변경(그[의] 사후에 이루어질)"''은 버전 번호를 π로 변경하는 것이며, 이 시점에서 남은 모든 버그는 영구적인 기능이 될 것이라고 말했다.[24]비슷한 방식으로, Metafont의 버전 번호는 e에 점근적으로 접근한다.[24] 2021년 2월 기준으로, 버전 번호는 2.71828182이다. Metafont는 또한 도널드 커누스가 그의 TeX 조판 시스템의 동반자로 고안했다.[24]
4. 3. 애플
클래식 Mac OS 시대에는 마이너 버전 번호가 ".1"을 넘는 경우가 드물었고, ".5"로 건너뛰는 경우가 있었다. Mac OS X는 "X"(10)가 제품 이름에 포함되어 모든 버전이 10으로 시작했다. OS X의 첫 번째 주요 릴리스는 10.0이었고, 이후 10.1, 10.2와 같이 후속 버전이 이어졌다. macOS 10.12부터는 이름에서 "X"가 삭제되었지만, 10.15까지 이 번호 매기기 방식이 유지되었다.[25]QuickTime과 Final Cut Pro는 버전 7에서 바로 버전 10(X)으로 건너뛰었다. Mac OS X와 마찬가지로, 이 프로그램들은 완전히 새로운 프로그램이었고, 주요 릴리스는 두 번째 숫자를, 마이너 릴리스는 세 번째 숫자를 증가시켜 표시했다.
macOS 11은 2020년 11월에 출시되었고,[27] macOS Monterey는 2021년 10월에 출시되어 주요 버전 번호가 12로 올라갔다.[28]
4. 4. 마이크로소프트 윈도우
마이크로소프트 윈도우 운영 체제는 처음에는 윈도우 1.0부터 윈도우 3.11까지 표준 버전 번호로 표기되었다. 이후 마이크로소프트는 제품 이름에서 버전 번호를 제외했다. 윈도우 95 (버전 4.0), 윈도우 98 (4.10) 및 윈도우 2000 (5.0)의 경우, 출시 연도가 제품 제목에 포함되었다.[29] 윈도우 2000 이후 마이크로소프트는 윈도우 서버 제품군을 만들었고, 이는 연도 기반 방식을 유지했지만 차이점이 있었다. 마이너 릴리스의 경우, 마이크로소프트는 제목에 "R2"를 접미사로 붙였다(예: 윈도우 서버 2008 R2 (버전 6.1)).[29] 이 스타일은 현재까지 일관성을 유지하고 있다. 그러나 윈도우의 클라이언트 버전은 일관된 스타일을 채택하지 않았다. 먼저, 윈도우 Me (4.90), 윈도우 XP (5.1) 및 윈도우 비스타 (6.0)와 같이 임의의 영숫자 접미사가 있는 이름을 받았다. 그런 다음, 마이크로소프트는 다시 제목에 증가하는 숫자를 채택했지만, 이번에는 버전 번호가 아니었다. 윈도우 7, 윈도우 8 및 윈도우 8.1의 버전 번호는 각각 6.1, 6.2 및 6.3이다.[29] 윈도우 10에서는 버전 번호가 10.0으로 상승했고[29], 이후 OS 업데이트는 빌드 번호 및 업데이트 빌드 개정 번호(UBR)만 증가했다.윈도우 10의 후속 제품인 윈도우 11은 2021년 10월 5일에 출시되었다. "11"이라는 이름에도 불구하고, 새로운 윈도우 릴리스는 주 버전 번호를 11로 올리지 않았다. 대신 윈도우 10에서 사용했던 것과 동일한 버전 번호 10.0을 유지했다.[30]
5. 기타 체계
소프트웨어 제작사 중 일부는 소프트웨어의 릴리스를 표시하기 위해 다른 방식을 사용한다. 데비안 프로젝트는 운영 체제의 릴리스에 주/부 버전 관리 체계를 사용하지만, 개발 중에는 안정, 불안정, 테스트 릴리스를 참조하기 위해 영화 ''토이 스토리''의 코드 이름을 사용한다.[31]
BLAG 리눅스 및 GNU는 매우 큰 버전 번호를 사용한다. 주 릴리스는 50000 및 60000과 같은 숫자를 가지며, 부 릴리스는 숫자를 1씩 증가시킨다(예: 50001, 50002). 알파 및 베타 릴리스는 주 릴리스 번호보다 약간 작은 십진수 버전 번호를 갖는다. 예를 들어 버전 20000의 알파 1은 19999.00071이고 버전 30000의 베타 2는 29999.50000이다. 2003년 9001부터 시작하여 2011년 기준 최신 버전은 140000이다.[32][33][34]
Urbit는 ''켈빈 버전 관리''를 사용한다(절대 온도 켈빈 척도에서 이름을 따옴). 소프트웨어 버전은 높은 숫자에서 시작하여 버전 0까지 카운트다운되며, 이 시점에서 소프트웨어는 완료된 것으로 간주되고 더 이상 수정이 이루어지지 않는다.[35][36]
6. 내부 버전 번호
소프트웨어는 제품명에 표시되는 버전 번호와는 다른 "내부" 버전 번호를 가질 수 있으며, 이는 일반적으로 버전 번호 매기기 규칙을 보다 일관되게 따른다. 예를 들어, 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으로 도약하면서 다섯 번째 주요 개정판에 불과하다.
7. 릴리스 전 버전
소프트웨어 릴리스 라이프 사이클의 여러 단계를 거치면서 사전 릴리스 버전을 표시하는 시스템이 일반적으로 사용된다.[38][39]
초기 단계의 프로그램은 그리스 문자의 첫 글자를 따서 "알파" 소프트웨어라고 불린다. 성숙되었지만 아직 출시 준비가 되지 않은 경우는 그리스 문자의 두 번째 글자를 따서 "베타" 소프트웨어라고 불린다. 알파 소프트웨어는 주로 개발자가 테스트하고, 베타 소프트웨어는 커뮤니티 테스트를 위해 배포된다.
일부 시스템에서는 1.0 릴리스에 가까워짐을 나타내기 위해 1 미만의 숫자 버전(예: 0.9)을 사용하는데, 이는 오픈 소스 소프트웨어 개발에서 흔히 볼 수 있다.[38][39] 기존 소프트웨어 패키지의 사전 릴리스 버전(예: 2.5)에는 버전 번호 뒤에 "a" 또는 "alpha"를 추가하여 2.5a 또는 2.5.a 와 같이 식별한다.
"릴리스 후보(release candidate)"라는 용어를 사용하기도 한다. 특정 버전으로 출시될 소프트웨어는 버전 태그 뒤에 "rc-#"를 붙여 릴리스 후보 번호를 표시하고, 최종 버전이 릴리스되면 "rc" 태그는 제거된다.
8. 릴리스 트레인
소프트웨어 릴리스 트레인은 여러 제품에 대한 버전 관리 소프트웨어 릴리스의 여러 개별 시리즈가 정기적인 일정에 따라 여러 "트레인"으로 출시되는 소프트웨어 릴리스 일정의 한 형태이다. 일반적으로 각 제품 라인에 대해 여러 개의 서로 다른 릴리스 트레인이 주어진 시간에 실행되며, 각 트레인은 계획된 일정에 따라 초기 릴리스에서 최종 성숙 및 중단으로 이동한다. 사용자는 프로덕션에 채택하기 전에 새로운 릴리스 트레인을 시험해 볼 수 있으며, 이를 통해 최신의 "생" 릴리스를 조기에 실험하는 동시에 새로운 릴리스 트레인이 성숙해짐에 따라 이전 트레인의 포인트 릴리스를 프로덕션 시스템에 적용하여 계속 사용할 수 있다.
IOS 소프트웨어 플랫폼은 수년 동안 여러 개의 서로 다른 트레인을 사용하여 릴리스 트레인 일정을 사용했다. 최근에는 Firefox 및 Android용 Fenix,[40] 이클립스,[41] LibreOffice,[42] 우분투,[43] Fedora,[44] Python,[45] digiKam[46] 및 VMware[47]를 포함한 여러 다른 플랫폼이 릴리스 트레인 모델을 채택했다.
9. 숫자 체계 수정
9. 1. 개발 릴리스에 대한 홀수 버전
리눅스 커널의 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와 같이 릴리스 주기가 긴 다른 일부 소프트웨어에서도 사용된다.
9. 2. 가장 중요한 요소 삭제
썬의 자바는 내부 버전 번호는 항상 1.''x''였지만 ''x''만 참조하여 마케팅되었다.[49] 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")와 같이 표기되었다. 썬은 솔라리스의 첫 번째 숫자를 삭제했는데, 솔라리스 2.8(또는 2.9)은 마케팅 자료에서 솔라리스 8(또는 9)으로 언급된다.[49]2010년대 초반 애스터리스크 오픈 소스 PBX 구축 키트에서도 비슷한 변화가 일어났는데, 프로젝트 리더들은 현재 버전 1.8.x가 곧 버전 10으로 이어질 것이라고 발표했다.[49]
이러한 방식은 버전 번호의 각 부분의 의미론적 중요성을 훼손하기 때문에 많은 사람들에게 비판을 받았지만,[49] 모질라( 파이어폭스의 경우)를 포함한 점점 더 많은 공급업체들이 채택하고 있다.
10. 버전 번호 순서 시스템
버전 번호는 초기의 단순 정수(1, 2, ...)에서 유리수(2.08, 2.09, 2.10)로 빠르게 변화하였고, 4:3.4.3-2와 같은 비수치적 "번호"로까지 발전하였다. 따라서 이러한 버전 번호는 문자열로 처리하는 것이 더 적합하다. 패키지 관리 기능을 포함하는 운영 체제는 서로 다른 소프트웨어 패키지의 버전 번호를 비교하기 위해 배포판별 알고리즘을 사용한다. 예를 들어, 레드햇 및 파생 배포판의 정렬 알고리즘은 데비안 계열 배포판과 다르다.
데비안에서는 버전 번호 청크의 선행 0을 무시하기 때문에 5.0005와 5.5는 동일하게 간주되고, 5.5 < 5.0006으로 간주되는 등 예기치 않은 버전 번호 정렬 동작이 발생할 수 있다. 이는 사용자에게 혼란을 야기하고, 문자열 일치 도구가 특정 버전 번호를 찾지 못하게 하거나, 패키지 관리에서 미묘한 버그를 일으킬 수 있다.
일부 소프트웨어 패키지는 정렬을 쉽게 하기 위해 ''주요.부.릴리스'' 체계의 각 구성 요소를 고정된 너비로 나타내기도 한다. 펄은 버전 번호를 부동 소수점 숫자로 나타내는데, 예를 들어 5.8.7 릴리스는 5.008007로 표현할 수 있다. 마이크로소프트 윈도우는 각 세그먼트를 고정 비트 너비로 묶는 방식을 사용하는데, 예를 들어 버전 번호 6.3.9600.16384는 16진법 0x0006000325804000으로 표현된다. 이러한 방식은 버전 번호의 세그먼트가 일정 값을 초과하면 문제가 발생할 수 있다.
11. 정치적, 문화적 의미
11. 1. 버전 1.0의 이정표
오픈 소스 커뮤니티는 소프트웨어를 조기에 자주 릴리스하는 경향이 있다.[38][39] 버전 1.0은 주요 마일스톤으로, 소프트웨어가 최소한 모든 주요 기능과 개발자가 해당 버전에 포함하고 싶어하는 기능을 갖추고 있으며 일반 릴리스에 충분히 신뢰할 수 있음을 나타낸다. 1991년에 버전 0.01로 처음 릴리스되었고, 1994년이 되어서야 버전 1.0.0에 도달한 리눅스 커널이 좋은 예시이다.[50][51] 한국의 개발 문화에서도 "빨리빨리" 문화와 잦은 업데이트를 선호하는 사용자들의 특성상, 버전 1.0 이전의 잦은 릴리스와 빠른 피드백 반영이 중요하게 여겨진다.11. 2. 마케팅으로서의 버전 번호
마케팅상의 이유로 버전 번호를 크게 건너뛰는 것은 비교적 흔한 관행이다.[53] 때로는 소프트웨어 공급업체가 1.0 릴리스를 건너뛰거나 후속 버전 번호로 빠르게 릴리스하는 경우가 있는데, 이는 많은 고객이 1.0 소프트웨어를 실제 운영에 사용할 만큼 성숙하지 않다고 여기기 때문이다. 예를 들어, dBase II의 경우처럼, 제품이 실제보다 더 성숙한 버전 번호로 출시되기도 한다.또는 경쟁업체의 버전 번호에 맞추기 위해 버전 번호를 높이기도 한다. 이는 마이크로소프트의 여러 제품 버전 번호, 아메리카 온라인, 선(Sun)의 솔라리스, 자바 가상 머신, SCO 유닉스, 워드퍼펙트에서 볼 수 있다. 마이크로소프트 엑세스는 마이크로소프트 워드의 버전 번호와 맞추기 위해 버전 2.0에서 버전 7.0으로 건너뛰었다.
마이크로소프트는 또한 "따라잡기" 버전 관리의 대상이 되기도 했다. 넷스케이프 브라우저는 인터넷 익스플로러에 맞춰 버전 5를 건너뛰고 6으로 출시되었지만, Mozilla 애플리케이션 제품군이 1.0 이전 개발 중에 사용자 에이전트 문자열에 버전 5를 상속받았고 넷스케이프 6.x가 Mozilla의 코드 베이스를 기반으로 구축되었기 때문이기도 하다.
경쟁업체에 보조를 맞추는 또 다른 예로는 슬랙웨어 리눅스가 1999년에 버전 4에서 버전 7로 건너뛴 경우가 있다.
11. 3. 미신
숫자 13에 대한 미신 때문에 일부 소프트웨어 버전에서 13을 건너뛰는 경우가 있다.[54] 마이크로소프트 오피스 2007의 내부 버전 번호는 12였으며, 다음 버전인 오피스 2010은 내부 버전이 14이다.[54] 비주얼 스튜디오 2013은 제품 버전 번호 12.0이며, 새로운 버전인 비주얼 스튜디오 2015는 버전 번호가 14.0이다.[54]록시오 토스트는 버전 12에서 버전 14로 넘어갔으며, 코렐의 워드퍼펙트 오피스 버전 13은 "X3" (로마 숫자 10과 "3")으로 판매되었고, 이 절차는 다음 버전인 X4까지 이어졌다. 코렐의 그래픽 스위트(코렐 드로우, 코렐 포토페인트)와 비디오 편집 소프트웨어 "비디오 스튜디오"에서도 마찬가지였다.
사이베이스는 Adaptive Server Enterprise 관계형 데이터베이스 제품에서 12.5에서 15.0으로 이동하면서 주요 버전 13과 14를 건너뛰었다. ABBYY 링고 사전은 12, x3 (14), x5 (15) 번호를 사용한다. SUSE 리눅스 엔터프라이즈는 버전 12 이후 버전 13과 14를 건너뛰고 2018년 7월에 SLES 15를 직접 출시했다.
한국에서도 숫자 4를 불길하게 여기는 문화 때문에, 소프트웨어 버전이나 제품 모델명에서 4를 건너뛰는 경우가 종종 있다.
11. 4. 괴짜 문화
SUSE 리눅스 배포판은 더글러스 애덤스의 ''은하수를 여행하는 히치하이커를 위한 안내서''에 언급된 "삶, 우주, 그리고 모든 것의 궁극적인 질문에 대한 답"인 42를 참조하여 버전 4.2로 시작했다. Slackware 리눅스 배포판은 leet를 참조하여 버전 13.37을 사용했다. Finnix는 "There Will Be No Finnix '95"라는 주장을 충족하기 위해 버전 93.0에서 100으로 건너뛰었는데, 이는 Windows 95를 언급한 것이다.[55] Tagged Image File Format 사양은 처음부터 42를 내부 버전 번호로 사용해 왔는데, 설계자들이 개발 지침과 충돌하기 때문에 생존 기간 동안 더 이상 변경하지 않을 것으로 예상했기 때문이다.12. 의의
12. 1. 소프트웨어 공학에서
버전 번호는 소비자가 소프트웨어 제품의 사본을 개발자가 출시한 최신 버전과 같이 다른 사본과 식별하거나 비교하는 데 사용된다.[6] 프로그래머나 회사에게 버전 관리는 종종 수정별 기준으로 사용되며, 소프트웨어의 개별 부분이 해당 부분의 새롭거나 이전 수정본과 비교 및 대조되는데, 이는 종종 협업 버전 관리 시스템에서 이루어진다.21세기 들어, 더 많은 프로그래머들이 시맨틱 버전 관리 정책과 같은 공식화된 버전 관리 정책을 사용하기 시작했다.[6] 이러한 정책의 목적은 다른 프로그래머가 코드 변경이 자신들이 작성한 것을 망가뜨릴 가능성이 있을 때 쉽게 알 수 있도록 하는 것이다. 이러한 정책은 소프트웨어 라이브러리 및 소프트웨어 프레임워크에 특히 중요하지만, 다른 애플리케이션에서 호출될 수 있는 명령줄 인터페이스 애플리케이션과 제3자에 의해 스크립팅 및/또는 확장될 수 있는 다른 모든 애플리케이션을 따르는 데에도 매우 유용할 수 있다.
버전 관리는 또한 소프트웨어를 패치하고 업그레이드하는 많은 방식, 특히 무엇을 어디로 업그레이드할지 자동으로 결정할 수 있도록 하는 데 필요한 관행이다.
12. 2. 기술 지원에서
버전 번호는 지원 담당자가 사용자가 실행 중인 코드를 ''정확히'' 파악할 수 있도록 돕는다. 이를 통해 이미 수정된 버그가 문제의 원인인지 배제할 수 있다.[6] 이는 프로그램에 상당한 사용자 커뮤니티가 있고, 기술 지원을 제공하는 사람이 코드를 작성한 사람이 아닌 경우에 특히 중요하다. 버전.수정.변경 스타일 번호 매기기는 정보 기술 담당자에게도 중요한데, 새 릴리스를 배포하기 전에 얼마나 많은 관심과 연구를 기울여야 하는지 결정하는 데 사용하기 때문이다.[6] 일반적으로 변경 사항이 클수록 무언가가 깨질 가능성이 더 크다.12. 3. 비 소프트웨어 사용
일부 파일 시스템(예: OpenVMS 파일 시스템)은 파일의 버전도 관리한다. 문서 버전 관리는 컴퓨터 및 소프트웨어 엔지니어링에서 사용되는 방식과 비교적 유사하며, 구조, 내용 또는 조건에 작은 변화가 있을 때마다 버전 번호가 1씩 증가하거나, 작성자의 개인적 선호도와 변경 사항의 크기 또는 중요도에 따라 더 작거나 큰 값으로 증가한다.소프트웨어 스타일의 버전 번호는 다른 미디어에서도 찾을 수 있다.
어떤 경우에는 직접적인 비유로 사용되기도 한다(예: 특별 기능을 추가한 영화
더 자주 사용되는 것은 첨단 기술과의 연관성을 활용하기 위한 것이며, 문자 그대로 '버전'을 나타내지는 않는다(예: 영화 ''Tron''의 비디오 게임 후속작인 ''Tron 2.0'', 또는 두 번째 시즌을 버전 2.0이라고 지칭하는 텔레비전 시리즈 ''The IT Crowd''). 특히 주목할 만한 사용 사례는 Web 2.0으로, 사용자 제작 콘텐츠, 사용성 및 상호 운용성을 강조하는 2000년대 초반의 웹사이트를 지칭한다.
기술 도면 및 CAD 소프트웨어 파일도 변경 사항을 추적하기 위해 일종의 원시적인 버전 관리 번호를 사용할 수 있다.
참조
[1]
논문
TENEX, a paged time sharing system for the PDP - 10
https://www.research[...]
1972-03
[2]
간행물
package interdependencies
https://lists.debian[...]
1994-02-25
[3]
간행물
Bug#1167: ELF development packages fail or have missing dependencies
https://lists.debian[...]
1995-07-30
[4]
문서
A Brief History of Debian
https://www.debian.o[...]
2021-10-26
[5]
웹사이트
PEP 440 – Version Identification and Dependency Specification
https://peps.python.[...]
2023-04-19
[6]
문서
Semantic Versioning
https://semver.org/
2013
[7]
서적
Proceedings of the 2020 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software
2020-08-16
[8]
웹사이트
Library Interface Versioning in Solaris and Linux
http://static.usenix[...]
[9]
웹사이트
Libtool's versioning system
https://www.gnu.org/[...]
[10]
웹사이트
Versioning Numbering Concepts – The Apache Portable Runtime Project
http://apr.apache.or[...]
2009-04-11
[11]
웹사이트
Daemonite: The science of version numbering
http://blog.daemon.c[...]
2009-04-11
[12]
서적
System z Parallel Sysplex Best Practices
https://books.google[...]
2011
[13]
웹사이트
Opera Changelogs for Windows
http://www.opera.com[...]
Opera Software
2014-11-06
[14]
웹사이트
Home
https://github.com/m[...]
2014-11-06
[15]
웹사이트
GNU Coding Standards: Releases
https://www.gnu.org/[...]
GNU Project
2014-05-25
[16]
문서
Debian Policy Manual
http://www.debian.or[...]
[17]
웹사이트
Java Edition version history
https://minecraft.wi[...]
2023-09-24
[18]
웹사이트
Advogato: Version numbering madness
http://www.advogato.[...]
2009-04-11
[19]
웹사이트
Calendar Versioning — CalVer
https://calver.org/
2019-10-10
[20]
웹사이트
International standard date and time notation
http://www.cl.cam.ac[...]
University of Cambridge
2009-04-11
[21]
웹사이트
Coding Horror: What's In a Version Number, Anyway?
https://blog.codingh[...]
2016-11-15
[22]
웹사이트
What does the "NT" stand for in Windows NT?
https://pc.net/helpc[...]
2022-08-13
[23]
웹사이트
PEP 440 – Version Identification and Dependency Specification
https://www.python.o[...]
[24]
학술지
The Future of TeX and Metafont
https://tug.org/TUGb[...]
2023-09-07
[25]
뉴스
Apple Releases macOS 10.13.3 Supplemental Update With Telugu Crash Fix
https://www.macrumor[...]
2018-03-26
[26]
뉴스
Apple turns macOS up to 11 – or to 10.16
https://appleinsider[...]
AppleInsider
2020-06-22
[27]
뉴스
Apple unveils macOS 11.0 Big Sur
https://techcrunch.c[...]
2020-06-22
[28]
뉴스
Apple macOS Monterey: Everything we know so far
https://bgr.com/tech[...]
BGR
2021-10-12
[29]
웹사이트
Announcing Windows 10
http://blogs.windows[...]
[30]
웹사이트
Windows 11: A new era for the PC begins today
https://blogs.window[...]
2021-10-04
[31]
웹사이트
Debian FAQ: 6.2.2 Where do these codenames come from?
https://www.debian.o[...]
2021-01-02
[32]
웹사이트
BLAG Linux And GNU
http://www.blagblagb[...]
2011-09-29
[33]
웹사이트
News and Updates: BLAG
http://distrowatch.c[...]
2011-09-29
[34]
웹사이트
blag download
http://www.blagblagb[...]
2011-09-29
[35]
웹사이트
Kelvin Versioning · jtobin.io
https://jtobin.io/ke[...]
2021-03-17
[36]
웹사이트
Toward a Frozen Operating System – Urbit
https://urbit.org/bl[...]
2021-03-17
[37]
웹사이트
Windows 10 NT kernel gets bumped from 6.4 to 10 in recent internal builds
https://windowsrepor[...]
2014-11-21
[38]
뉴스
ToaruOS 1.0 Open Source OS Released After 6+ Years Of Development
https://fossbytes.co[...]
2017-02-13
[39]
웹사이트
Wine Headed For a 1.0 Release. Finally.
https://www.wired.co[...]
Wired
2017-05-23
[40]
웹사이트
Firefox Release Calendar – MozillaWiki
https://wiki.mozilla[...]
[41]
웹사이트
Simultaneous Release – Eclipsepedia
https://wiki.eclipse[...]
[42]
웹사이트
ReleasePlan – The Document Foundation Wiki
https://wiki.documen[...]
[43]
웹사이트
Releases – Ubuntu Wiki
https://wiki.ubuntu.[...]
[44]
웹사이트
Releases – Fedora Project Wiki
https://fedoraprojec[...]
[45]
웹사이트
PEP 0 – Index of Python Enhancement Proposals (PEPs)
https://www.python.o[...]
[46]
웹사이트
Release Plan
https://digikam.org/[...]
2018-03-25
[47]
웹사이트
VMware Product Release Tracker (vTracker)
https://www.virten.n[...]
2015-02-13
[48]
뉴스
Node.js is SemVer
http://nodesource.co[...]
2015-09-15
[49]
웹사이트
The Evolution of Asterisk (or: How We Arrived at Asterisk 10) | Inside the Asterisk
http://blogs.digium.[...]
Digium, Inc
2011-07-21
[50]
간행물
Notes for linux release 0.01
https://www.kernel.o[...]
kernel.org
1991
[51]
뉴스
Aug. 25, 1991: Kid From Helsinki Foments Linux Revolution
https://www.wired.co[...]
WIRED
2009-08-25
[52]
서적
Practical MythTV: Building a PVR and Media Center PC
https://books.google[...]
Springer-Verlag New York, Inc.
2007-12-15
[53]
웹사이트
Slackware FAQ
http://www.slackware[...]
[54]
웹사이트
Office 2010 FAQ
http://www.winsupers[...]
2009-05-14
[55]
웹사이트
I'm sorry
http://lists.colobox[...]
2010-10-23
[56]
문서
[57]
문서
[58]
웹사이트
.NET Framework 4: Version Class
http://msdn.microsof[...]
Microsoft MSDN
2011-02-25
[59]
웹사이트
Java SE Documentation: Appendix 2: Sun-Supported Specification-Version and Implementation-Version Formats
http://download.orac[...]
Oracle
2011-02-25
[60]
문서
[61]
문서
[62]
문서
[63]
문서
[64]
문서
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com