소프트웨어 버전 관리

Software versioning

소프트웨어 버전 관리는 고유한 버전 이름 또는 고유한 버전 번호를 컴퓨터 소프트웨어의 고유한 상태에 할당하는 프로세스입니다.주어진 버전 번호 범주(예: 줄자 또는 마이너) 내에서 이러한 번호는 일반적으로 증가하는 순서대로 할당되며 소프트웨어의 새로운 개발에 대응합니다.세분화된 수준에서 수정 제어는 종종 증분적으로 다른 버전의 정보를 추적하기 위해 사용됩니다. 이 정보가 컴퓨터 소프트웨어인지 여부에 관계없이 말입니다.

최신 컴퓨터 소프트웨어는 종종 두 가지 소프트웨어 버전 관리 방식을 사용하여 추적됩니다. 리비전 관리 번호와 같은 내부 버전 번호와 의미 버전[1] 또는 프로젝트 코드 이름과 같이 일반적으로 훨씬 더 자주 변경되지 않는 릴리스 버전입니다.

역사

파일 번호는 특히 기업뿐만 아니라 공공 행정 기관에서도 파일 또는 사례를 고유하게 식별하기 위해 사용되었습니다.컴퓨터 파일의 경우,[2] 이 방법은 MITS ITS 파일 시스템(나중에 1972년에 PDP-10용 TENEX 파일 시스템)에 최초로 도입되었습니다.

이후 버전 및 종속성을 포함한 파일 목록이 추가되었습니다.Debian과 같은 Linux 디스트리뷰션은 패키지 간의 의존성을 해결할 수 있는 패키지 관리 소프트웨어를 초기에 만들었습니다.데비안들은 처음에 패키지가 그것에 의존하는 다른 패키지를 알고 있다는 것을 시도했다.1994년부터는 이 아이디어가 뒤집혔기 때문에 패키지는 필요한 패키지를 알고 있었습니다.패키지를 인스톨 할 때는, 필요한 패키지도 자동적으로 계산해, 목적의 패키지와 함께 인스톨 하기 위해서, 의존적인 해결 방법을 사용했습니다.업그레이드를 용이하게 하기 위해 최소 패키지 버전이 도입되었습니다.따라서 어떤 버전이 필요한 [3][4][5]버전보다 최신 버전인지 식별하기 위해 번호 부여 방식이 필요했습니다.

스킴

소프트웨어의 다른 버전을 추적하기 위해 다양한 버전 번호 부여 방식이 작성되었습니다.컴퓨터의 보급에 의해서, 이러한 스킴이 컴퓨팅 이외의 상황에서도 사용되고 있습니다.

시퀀스 기반 식별자

버전 번호 시퀀스의 예

시퀀스 베이스의 소프트웨어 버전 관리 방식에서는, 각 소프트웨어 릴리스에는, 1개 이상의 번호 또는 문자의 시퀀스로 이루어진 일의의 ID 가 할당됩니다.이것은 공통성의 범위입니다.순서의 수, 개별 순서의 의미 속성, 순서의 증가 수단과 같은 영역에서 체계는 매우 다양합니다.

중요도 변경

일부 방식에서는 시퀀스 기반 식별자를 사용하여 릴리스 간 변경의 중요성을 전달합니다.변경은 중요도 레벨별로 분류되며 릴리스 간에 변경할 시퀀스의 결정은 이전 릴리스로부터의 변경의 중요도에 따라 결정됩니다.이 경우 첫 번째 시퀀스는 가장 중요한 변경에 대해 변경되며 첫 번째 시퀀스 이후의 시퀀스 변경은 중요도가 감소하는 변경을 나타냅니다.

스킴에 따라서는 코드 변경, 기능 포인트 추가 또는 삭제, 새로운 버전의 도입에 필요한 작업에 대한 고객에게 미치는 영향, 버그 또는 선언되지 않은 파손의 위험, 비주얼 레이아웃의 변경 정도, 새로운 기능의 수, 또는 제품 개발자의 거의 모든 것에 의해 중요도가 평가될 수 있습니다.마케팅 담당자는 새로운 버전의 "좋은 점"을 강조하려는 마케팅 욕구를 포함하여 중요하다고 생각합니다.

시멘틱 버전 관리

시멘틱 버전 관리 3부 버전 번호

시멘틱 버전 관리(일명 SemVer)[1]는 3부분 버전 번호(메이저)를 사용하는 널리 채택된 버전[6] 체계입니다.Minor.Patch), 옵션 사전 릴리스 태그 및 옵션 빌드 메타 태그가 있습니다.이 체계에서는 위험과 기능성이 중요한 척도이다.브레이크 변경은 메이저 수를 늘림으로써 표시됩니다(고위험). 새로운 비브레이크 기능은 마이너 수를 늘림으로써(중위험), 기타 모든 브레이크하지 않는 변경은 패치 수를 증가시킵니다(최저위험).프리리스 태그(-alpha, -beta)의 존재는 중대한 리스크와 큰 제로(0.y.z)의 존재를 나타냅니다.이는 잠재적으로 파손될 수 있는 변경(가장 높은 리스크)을 포함할 수 있는 진행 중인 작업을 나타내기 위해 사용됩니다.SemVer 버전에서 호환성을 추론하는 예로서 API 버전 2.1.5에 의존하는 소프트웨어는 버전 2.2.3과 호환되지만 반드시 3.2.4와 호환되지는 않습니다.

개발자는 중요한 기능이 추가되었음을 나타내기 위해 한 번에 여러 개의 마이너 버전을 점프하는 것을 선택할 수 있지만 Internet Explorer 5에서 5.5로, Adobe Photoshop 5에서 5.5로 등 메이저 버전 번호를 증가시키기에 충분하지 않습니다.이는 소프트웨어 사용자에 대한 업그레이드의 가치를 강조하기 위해 또는 Adobe의 경우처럼 메이저버전의 중간 릴리스를 나타내기 위해 수행될 수 있습니다(Blender 버전 2.91 또는 Minecraft Java Edition에서처럼 시퀀스 기반 버전 수준이 반드시 한 자리 수로 제한되는 것은 아닙니다).

다른 접근방식은 줄자 및 마이너 번호와 함께 릴리스 유형을 나타내는 영숫자 문자열(예: "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 (더 많은 버그가 발견될 경우)처럼 보일 수 있습니다.이 방식에서는 릴리스 후보 단계에서 새로운 기능을 잠그고 변경을 중단하는 것이 일반적입니다.또 일부 팀에서는 베타도 타깃릴리즈에서의 컨버전스를 확보하기 위해 버그 수정에만 잠겨 있습니다.

다른 방식은 개별 시퀀스에 의미를 부여합니다.

major.build[.build](파일명: 1.2.12.102)
major.major[.maintenance][.빌드] (표준: 1.4.3.5249)

다시 말씀드리지만, 이러한 예에서, "작은" 변경과 반대로 "큰"을 구성하는 것에 대한 정의는 전적으로 주관적이며, "구축"을 정의하는 것, 또는 "개정"이 "작은" 변경과 어떻게 다른지에 따라 작성자에게 달려 있습니다.

Solaris 및 Linux 공유 라이브러리는 current.revision.age 형식을 사용할 수 있습니다.[7][8]

현재:라이브러리가 실장하고 있는 최신 인터페이스 번호.
리비전:현재 인터페이스의 실장 번호.
age: 라이브러리가 실장하는 최신 인터페이스와 오래된 인터페이스의 차이.세 번째 필드의 사용은 libtool에만 해당됩니다.다른 사람들은 다른 의미를 사용하거나 단순히 무시하는 경우가 있습니다.

상대적인 변경의 중요성과 버전 지정이라는 유사한 문제가 서적 출판에도 존재합니다.서적 출판에서는 다양한 기준에 따라 에디션 번호나 이름을 선택할 수 있습니다.

대부분의 독점 소프트웨어에서 소프트웨어 제품의 최초 출시 버전은 버전 [citation needed]1입니다.

호환성 정도

일부 프로젝트에서는 주 버전 번호를 사용하여 호환되지 않는 릴리스를 나타냅니다.Apache Portable Runtime(APR)[9]과 FarCry [10]CMS가 두 가지 예입니다.

프로그래머는 하위 호환성을 위해 새로운 소프트웨어를 작성하는 경우가 많습니다. 즉, 새로운 소프트웨어는 소프트웨어의 이전 버전(이전 프로토콜 및 파일 형식 사용) 및 최신 버전(최신 프로토콜 및 파일 형식 사용)과 올바르게 상호 작용하도록 설계되었습니다.예를 들어, IBM z/OS는 동일한 sysplex에서 실행되는 3개의 주요 운영 체제 버전에서 올바르게 작동하도록 설계되었습니다.이를 통해 고가용성 컴퓨터 클러스터를 실행하는 사용자는 한 번에 하나의 시스템을 [11]종료, 업그레이드 및 복원하는 동안 대부분의 컴퓨터를 가동 상태로 유지할 수 있습니다.

패킷 헤더 및 파일 형식에는 버전 번호가 포함되어 있는 경우가 많습니다.버전 번호를 작성한 소프트웨어의 버전 번호와 같은 경우도 있고, 소프트웨어 버전 번호와는 무관한 "프로토콜 버전 번호"도 포함되어 있습니다.더 이상 사용되지 않는 오래된 프로토콜과 파일 형식을 처리하는 코드는 종종 까다롭습니다.

개발 단계 지정

실험 단계(알파 또는 베타)의 소프트웨어는 종종 시퀀스의 첫 번째("주요") 위치에 0을 사용하여 상태를 지정합니다.단, 이 스킴은 초기 단계에만 유효하며 버전 번호가 [1]이미0을 넘고 있는 확립된 소프트웨어를 탑재한 이후의 릴리스에서는 유효하지 않습니다.

새로운 릴리스의 상태를 나타내기 위해 다음과 같은 여러 가지 방식이 사용됩니다.

  • 영숫자 서픽스는 시멘틱버전 [1]관리에서 일반적으로 채택되는 방식입니다.이 스킴에서는, 버전에서는, 상태를 나타내기 위해서, 대시와 영숫자가 부가되어 있습니다.
  • 숫자 상태는 숫자를 사용하여 상태가 시퀀스의 일부인 것처럼 표시하는 체계입니다.일반적인 선택은 4개의 위치 버전 관리를 위한 세 번째 위치입니다.
  • 숫자 90+는 숫자를 사용하는 또 다른 방식이지만 이전 버전의 숫자로는 분명합니다.마지막 위치에 있는 큰 숫자(일반적으로 90 이상)가 사용됩니다.이것은 Fontconfig와 같은 오래된 오픈 소스 프로젝트에서 일반적으로 사용됩니다.
개발단계 지표 비교
단계. 섬버 수. 상태 Num 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
릴리스 후보 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.3.5 1.2.5

2개의 순수 숫자 형식을 사용하면 시멘틱버전 관리에서 볼 수 있는 "alpha < beta < rc < no prefix"의 비교를 처리하기 위해 필요한 특별한 로직이 배제됩니다.(의미적 버전 관리는 실제로 개발 단계에 대한 특정 용어를 지정하는 것이 아닙니다.비교는 단순히 사전적 순서로 이루어집니다.)

시퀀스의 증가

숫자 버전 번호가 증가하는 방법에 대해서는 두 가지 학파가 있습니다.MediaWiki를 포함한 대부분의 자유 및 오픈 소스 소프트웨어 패키지는 버전을 일련의 개별 번호로 취급하며, 마침표로 구분하여 1.7.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2 등의 순서로 처리합니다.

한편, 소프트웨어 패키지에 따라서는, 릴리스가 10 진수(1.7, 1.8, 1.81, 1.82, 1.9 등)로 식별되는 경우도 있습니다.NetWare, DOS, Microsoft Windows 등 1980년대에는 10진수 버전이 일반적이지만 2000년대에도 Opera 및 Movable [13]Type에서[12] 사용되고 있습니다.10진법에서 1.81은 1.8 이후의 마이너버전이며, 유지 보수 릴리스(버그 수정 전용)는 1.81a 또는 1.81b와 같은 알파벳 접미사로 표시될 수 있습니다.

표준 GNU 버전 번호 부여 방식은 major.minor.revision이지만 [14]Emacs는 메이저 번호 (1)이 삭제되고 사용자 사이트 리비전이 추가된 다른 방식을 사용한 주목할 만한 예입니다.이러한 리비전은 원래 Emacs 패키지에서는 항상 제로이지만 [15]디스트리뷰터에 의해 증가합니다.마찬가지로 Debian 패키지 번호 앞에는 옵션인 "epoch"가 붙습니다.이 "epoch"는 버전 관리 방식을 [16]변경하는 데 사용됩니다.

리셋

경우에 따라서는 개발자가 메이저버전 번호를 리셋 할 수도 있습니다.이는 새로운 개발 단계가 출시되는 것을 나타내기 위해 사용되는 경우가 있습니다.예를 들어 마인크래프트 알파는 버전 1.0.0에서 1.2.6으로, 베타 버전이 출시될 때 메이저 버전 번호를 리셋하고 1.0에서 1.8로 실행했다.게임이 완전히 출시되자 메이저 버전 번호가 다시 1.0.[17]0으로 리셋되었습니다.

시퀀스의 분리

인쇄 시 시퀀스는 문자로 구분될 수 있습니다.문자 선택과 사용법은 스킴에 따라 달라집니다.다음 목록은 동일한 릴리스(제2의 제1의 [original research?]리비전에 대한 제4의 제2의 레벨 리비전에 대한 제13의 제3의 레벨 리비전)의 분리 스킴의 가상적인 예를 나타내고 있습니다.

  • 스킴에서는, 모든 시퀀스간에 같은 문자를 사용할 수 있습니다.2.4.13, 2/4/13, 2-4-13
  • 분리할 시퀀스의 스킴 선택이 일관되지 않을 수 있으며 일부 시퀀스는 분리되지 않을 수 있습니다: 2.413
  • 동일한 식별자 내에서 스킴의 문자 선택이 일치하지 않을 수 있습니다: 2.4_13

마침표를 사용하여 시퀀스를 분리할 경우 소수점을 나타낼 수도 있고 나타낼 수도 없습니다. 다양한 해석 스타일은 "계속되는 시퀀스" 섹션을 참조하십시오.

시퀀스 수

소프트웨어 빌드(Microsoft에서 사용)를 나타내는 공개되지 않은 네 번째 숫자가 있을 수 있습니다.Adobe Flash는 10.1.53.64에서와 같이 4부분 버전 번호가 공개적으로 표시되는 경우입니다.일부 회사에는 제조 날짜도 포함되어 있습니다.버전 번호에는 Lotus 1-2-3 Release 1a와 같은 문자 및 기타 문자가 포함될 수도 있습니다.

음수

일부 프로젝트에서는 음수 버전 번호를 사용합니다.예를 들어 SmartEiffel 컴파일러는 -1.0부터 시작하여 0.0까지 [15]카운트됩니다.

발매일

CalVer 형식의 Street Fighter EXsplash 화면: "961219 USA"

많은 프로젝트에서는 캘린더 버전 관리(CalVer라고도[18] 함)라는 날짜 기반 버전 관리 체계를 사용합니다.

Ubuntu Linux는 캘린더 버전 관리를 사용하는 프로젝트의 한 예입니다. 예를 들어 Ubuntu 18.04는 2018년 4월에 출시되었습니다.이는 개발 일정 및 지원 일정에 쉽게 관련될 수 있다는 장점이 있습니다.아케이드 게임 Street Fighter EX와 같이 일부 비디오 게임에서는 날짜를 버전화하기도 합니다.부팅 시 버전 번호를 날짜 및 지역 코드(예: 961219 ASIA)[citation needed]로 표시합니다.

예를 들어 파일 이름 등 버전 관리에서 날짜를 사용하는 경우 ISO 8601[19] 스킴 YYY-MM-DD를 사용하는 것이 일반적입니다.이는 쉽게 오름차순 또는 내림차순으로 문자열 정렬이 가능하기 때문입니다.하이픈이 생략될 수 있습니다.와인 프로젝트에서는 이전에 날짜 버전 관리 방식을 사용했습니다. 날짜 버전 관리 방식에서는 "와인 20040505"[citation needed]와 같이 연도 다음 달과 출시 날짜를 사용했습니다.Minecraft는 유사한 버전 포맷을 사용했지만 대신 DDMMHH를 사용했습니다. 예를 들어 rd-132211은 5월 13일, 2211은 22:11입니다.

Microsoft Office 빌드 번호는 인코딩된 [20]날짜입니다.첫 번째 두 자리는 프로젝트가 시작된 해 1월부터 경과한 월수를 나타냅니다(각 메이저 Office 릴리스는 다른 프로젝트입니다).마지막 두 자리는 그 달의 날짜를 나타냅니다.3419일은 프로젝트가 [citation needed]시작된 해의 1월 이후 34개월째의 19일입니다.

연도별로 버전을 식별하는 다른 예로는 Adobe Illustrator 88 및 WordPerfect Office 2003이 있습니다.버전을 나타내기 위해 년을 사용하는 경우 일반적으로 마케팅을 목적으로 하며 실제 버전 번호도 존재합니다.예를 들어, Microsoft Windows 95 는 내부적으로 MS-DOS 7.00 와 Windows 4.00 으로 버전 되어 있습니다.또, Microsoft Windows 2000 Server 는 내부적으로 Windows NT 5.0 으로 버전 되어 있습니다(「NT」는 [original research?]원래 제품명을 참조하고 있습니다).

파이썬

Python Software Foundation은 PEP 440 – 버전 식별 및 종속성 [21]사양서를 발행하여 획기적인 세그먼트, 릴리스 세그먼트, 릴리스 전 및 릴리스 세그먼트, 개발 릴리스 세그먼트를 정의하는 유연한 방식을 개략적으로 설명하고 있습니다.

TeX

TeX에는 독특한 버전 번호 부여 시스템이 있습니다.버전 3 이후 업데이트는 끝에 추가 숫자를 추가하여 나타나며 버전 번호가 점근적으로 "에 접근합니다.단일 번호 형식입니다.버전 번호는 자릿수입니다.현재 버전은 3.141592653입니다.이는 TeX가 매우 안정적이고 사소한 업데이트만 예상되고 있음을 나타냅니다.TeX 개발자인 Donald Knuth는 "완전히 최종적인 변경(그의 사망 후에 이루어짐)"은 버전 번호를 ,로 변경하는 것이며, 이 시점에서 남아있는 모든 버그가 영구적인 [22]기능이 될 것이라고 말했습니다.

마찬가지로 메타폰의 버전 번호는 점근적으로 e에 접근합니다.

사과

클래식한 Mac OS 시대에는 마이너 버전 번호가 ".1"을 넘는 경우는 거의 없었습니다.그들이 그렇게 했을 때, 그들은 보통 바로 ".5"로 뛰어올랐고, 이는 이 릴리스가 "더 의미 있는"[a] 것임을 암시한다.따라서 "8.5"는 "Mac OS 8.5.5"를 대표하는 자체 릴리스로 마케팅되었으며, 8.6은 "8.5.1"을 의미했습니다.

Mac OS X는 제품 이름에 "X"(10의 로마 숫자)가 있었기 때문에 이러한 경향에서 벗어났습니다.그 결과 OS X의 모든 버전은 숫자 10으로 시작되었습니다.OS X의 첫 번째 메이저릴리즈에는 버전 번호10.0이 부여되었지만 다음 메이저릴리즈는 11.0이 아닙니다대신 10.1의 번호가 매겨졌고, 그 후 각 메이저릴리즈마다 10.2, 10.3 등의 번호가 매겨졌습니다.따라서 OS X의 11번째 메이저버전은 "10.10"이라는 라벨이 붙었습니다."X"는 macOS 10.12에서 이름에서 삭제되었지만 이 번호 체계는 macOS 10.15에서 계속되었습니다."X" 기반 버전 관리 체계에서는 (두 번째가 아닌) 세 번째 숫자가 마이너 릴리스를 나타내며, 이 수준 이하의 추가 업데이트와 새로운 메이저 버전 출시 후에 출시되는 OS X의 특정 메이저 버전에 대한 업데이트는 "보조 업데이트"[23]라는 제목으로 지정되었습니다.

로마숫자 X는 여러 제품군에 걸쳐 마케팅 목적으로 동시에 사용되었습니다.QuickTime과 Final Cut Pro는 모두 버전 7에서 버전 10, QuickTime X와 Final Cut Pro X로 직접 이동했습니다. Mac OS X 자체와 마찬가지로 제품은 이전 버전으로 업그레이드된 것이 아니라 최신 프로그램입니다.OS X와 마찬가지로 이들 프로그램의 메이저릴리즈에서는 두 번째 숫자가 증가했고 마이너릴리즈에서는 세 번째 숫자가 사용되었습니다."X"는 MacOS 11.0의 출시와 함께 Final Cut의 이름에서 삭제되었고 (아래 참조), Quick Time의 브랜딩은 2011년에 AVFundation에 의해 폐지되었을 때(Quick Time 비디오를 재생하기 위한 프로그램은 처음부터 Quick Time Player로 이름 붙여졌을 뿐이었다.

애플의 다음 macOS 릴리스(잠정 번호 10.[24]16)는 2020년 [25]6월 WWDC에서 macOS 11.0으로 공식 발표되었습니다.다음 macOS 버전인 macOS Montrey는 WWDC 2021에서 출시되었으며 메이저 버전 번호를 [26]12로 올렸습니다.

Microsoft Windows

Microsoft Windows operating system에는, 최초로 Windows 1.0 ~ Windows 3.11 의 표준 버전 번호가 붙어 있습니다.그 후, Microsoft 는 제품명으로부터 버전 번호를 제외했습니다.Windows 95(버전 4.0), Windows 98(4.10) 및 Windows 2000(5.0)의 경우는, 제품 타이틀에 릴리스 연도가 포함되어 있습니다.Windows 2000 이후, Microsoft 는 Windows Server 패밀리를 작성했습니다.이 패밀리는 다음과 같은 차이점을 가지고 연차 스타일을 계속했습니다.마이너 릴리스의 경우, Microsoft 에서는, Windows Server 2008 R2(버전 6.1)등의 제목에 「R2」를 붙였습니다.이 스타일은 지금까지도 일관성이 있었다.그러나 클라이언트 버전의 Windows는 일관된 스타일을 채택하지 않았습니다.우선, Windows Me(4.90), Windows XP(5.1), Windows Vista(6.0)와 같이 임의의 영숫자 서픽스를 가지는 이름을 받았습니다.그 후, 마이크로소프트는 다시 한번 제목에 증분 번호를 채택했지만, 이번에는 버전 번호가 아니었다. Windows 7, Windows 8, 및 Windows 8.1의 버전 번호는 각각 6.1, 6.2 및 6.3이다.Windows 10 에서는, 버전 번호가[27] 10.0 으로 껑충 뛰었고, 그 후의 OS 의 업데이트는 빌드 번호와 UBR(Update Build Revision) 번호의 증가만을 나타내고 있습니다.

Windows 10의 후속 버전인 Windows 11은 2021년 10월 5일에 출시되었습니다."11"이라고 이름 붙여졌음에도 불구하고, 새로운 Windows 릴리스는 메이저 버전 번호를 11로 올리지 않았습니다.대신 Windows [28]10에서 사용하는 버전 번호 10.0을 그대로 유지했습니다.

기타 스킴

일부 소프트웨어 생산자는 소프트웨어 릴리스를 나타내기 위해 다른 방식을 사용합니다.Debian 프로젝트는 운영 체제의 릴리스에 메이저/마이너 버전 관리 체계를 사용하지만, 개발 중에 영화 토이스토리의 코드 이름을 사용하여 안정,[29] 불안정 및 테스트 릴리스를 나타냅니다.

BLAG Linux 및 GNU는 매우 큰 버전 번호를 특징으로 합니다.메이저 릴리스는 50000 및 60000과 같은 번호를 가지지만 마이너 릴리스는 번호를 1(50001, 50002) 늘립니다.알파 및 베타 릴리스에는 메이저릴리즈 번호보다 약간 작은 10진수 버전 번호가 부여됩니다(버전 20000의 알파1의 경우 19999.00071 및 29999 등).버전 30000의 베타 2의 경우 50000.2003년 9001을 시작으로 2011년 현재 최신 버전은 140000입니다.[30][31][32]

Urbit는 Kelvin 버전 관리(절대 Kelvin 온도 눈금에서 따온 이름)를 사용합니다.소프트웨어 버전은 높은 수치로 시작하여 버전 0까지 카운트다운됩니다.이 시점에서 소프트웨어는 종료된 것으로 간주되며 더 이상의 변경은 [33][34]이루어지지 않습니다.

내부 버전 번호

소프트웨어에는 제품명에 표시되는 버전 번호와 다른 "내부" 버전 번호가 있을 수 있습니다(일반적으로 버전 번호 규칙을 더 일관되게 따릅니다).예를 들어 Java SE 5.0의 내부 버전 번호는 1.5.0이며 NT 4의 Windows 버전에서는 Windows 2000은 NT 5.0, XP는 Windows NT 5.1, Windows Server 2003 및 Windows XP Professional x64 Edition은 NT 5.2, Windows Server 6과 같은 표준 수치 버전이 내부적으로 계속됩니다.d Windows 7은 NT 6.1, Windows Server 2012 및 Windows 8은 NT 6.2, Windows Server 2012 R2 및 Windows 8.1은 NT 6.3이지만 Windows 10의 첫 번째 버전은 10.0(10.0.10240)이었습니다.다만, Windows NT의 첫 번째 릴리스는 (당시 Windows 릴리스 번호와 일치하도록) 3.1이라는 번호가 매겨져 있고, Windows 10이 론칭한 버전은 6.3에서 10.0으로 비약하고 있기 때문에, Windows NT는 5번째 메이저리비전에 불과하다는 점에 주의해 주세요.

프리리스 버전

프로그램은 소프트웨어 생명 주기의 단계를 통해 활로가 다양한 버전 관리 계획 위의 목록과 함께, 시사회 버전을 나타내는 표시 제도를 일반적으로 사용된다.

은 어린 단계다 프로그램을 자주, 그리스 알파벳의 첫번째 편지 후"알파"이라고 소프트웨어에게 불립니다.후에 그들은 하지만 아직 석방을 위해 준비가 되지 않았다 성숙한, 그들은 그리스 알파벳의 두번째 편지 후"베타"이라고 소프트웨어에게 불릴 수 있다.반면 베타 소프트웨어 공동체 시험에 배포된다 일반적으로 알파 소프트웨어 개발자들로만 시험한다.

몇몇 시스템 수치 버전 1(0.9와 같은)마지막"1.0"석방에 대한 그들의 접근을 제안하기 위해 사용한다.오픈 소스 소프트웨어에 이것은 일반적인 관례이다.[35][36]경우회에서 비상한 버전은 기존의 소프트웨어 패키지(예를 들어 버전 2.5)을 위한 것이다 하지만, 그렇다면"를"또는"알파"버전 번호에 추가할 수 있다.그래서 250출시의 알파 버전 2.5a 또는 2.5.a로 확인될 수 있다.

다른 하나의 대안은 그래서, 곧 특정한 버전으로 발표될 예정이다 소프트웨어 패키지 그 버전 태그"#rc-"에 이어해제 후보자의 번호 여부를 나타내는 값을 옮길 수도 있pre-release 버전으로"방출 후보"로, 참조할 때 최종 버전이 발표되는,"라머 반경"태그를 제거한다.

릴리스 트레인

에서 업데이트:2007년 11월 버전 소프트웨어 출시의 여러 제품에 대한 뚜렷한 시리즈를 수"기차"의 정기적으로에 숫자를로 방출되는 소프트웨어 방류 계획의 소프트웨어 출시 열차는 한 형태이다.일반적으로 각 제품 라인에 대한, 다른 출시 열차의 수가 주어진 시간에, 각 열차는 초기에 실린 궁극적으로 성숙하고 은퇴를 계획된 스케줄에 다가오는 달리고 있다.사용자들은 새로운 방출 기차로 생산을 위해 그것을 적용하기 전에, 전으로 성숙해 지기가 새 출시 열차로 옮기기로 그들의 생산 시스템을 위한 이전 기차의 관점 출시를 계속해서 따라가그들 새로운," 원", 방출과 일찍 실험해 볼 수 있도록 실험할 수 있다.

시스코의 IOS 소프트웨어 플랫폼에서는 수년 동안 많은 개별 열차와 함께 릴리즈 트레인 일정이 사용되었습니다.최근에는 Android,[37] Eclipse,[38] LibreOffice,[39] Ubuntu,[40] Fedora,[41] [42]Python, digiKam[43] 및 VMware용[44] Firefox와 Fenix를 포함한 많은 플랫폼이 출시 트레인 모델을 채택하고 있습니다.

숫자 시스템 수정

개발 릴리스용 홀수 버전

1.0 시리즈와 2.6.x 시리즈 사이에서 Linux 커널에서는 개발 릴리스를 나타내는 홀수 마이너버전 번호, 안정된 릴리스를 나타내는 마이너버전 번호까지 사용했습니다.Linux 커널 version버전 번호 매기기 참조.예를 들어 Linux 2.3은 Linux 커널의 두 번째 주요 설계의 개발 패밀리였고 Linux 2.4는 Linux 2.3이 성숙된 안정적인 릴리스 패밀리였습니다.Linux 커널의 보조 버전 번호 뒤에 릴리스 번호가 오름차순으로 표시됩니다(예: Linux 2.4.0 → Linux 2.4.22).2.6 커널의 2004년 출시 이후 Linux는 이 시스템을 사용하지 않게 되었고 출시 주기도 훨씬 짧아졌습니다.

릴리스 사이클이 긴 일부 소프트웨어(Node.js 버전 0.12 이하, GNOME 및 Wine 등)에서는 같은 홀수 짝수 시스템이 사용됩니다.본사.[45]

가장 중요한 요소 삭제

Sun의 Java는 때때로 하이브리드 시스템을 가지고 있었는데, 내부 버전 번호는 항상 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은 또한 Solaris의 첫 번째 숫자를 삭제했습니다.Solaris 2.8(또는 2.9)은 마케팅 자료에서 Solaris 8(또는 9)로 불립니다.

2010년대 초에 Asterisk 오픈 소스 PBX 구축 키트에서도 비슷한 움직임이 있었습니다.프로젝트 리더는 현재 버전 1.8.x가 곧 버전 [46]10으로 이어질 것이라고 발표했습니다.

이 접근방식은 버전 번호 섹션의 의미적 의미를 깨뜨리기 때문에 많은 벤더에 의해 채택되고 있습니다.이 접근방식은 Mozilla(Firefox용)를 포함한 많은 벤더에 의해 채택되고 있습니다.

버전 번호 주문 시스템

버전 번호는 단순한 정수(1, 2, ...)에서 유리수(2.08, 2.09, 2.10)로, 다음으로 4:3.4.3-2와 같은 비숫자 "숫자"로 매우 빠르게 진화합니다.따라서 이러한 복잡한 버전 번호는 문자열로 취급하는 것이 좋습니다.패키지 관리 기능(모든 사소한 Linux 또는 BSD 배포 등)을 포함하는 운영 체제에서는 배포별 알고리즘을 사용하여 서로 다른 소프트웨어 패키지의 버전 번호를 비교합니다.예를 들어 Red Hat의 순서 알고리즘과 파생 분포는 Debian-like 분포의 순서 알고리즘과 다르다.

놀라운 버전 번호 순서 부여 구현 동작의 예로서 Debian에서는 선행 0이 청크로 무시되므로 5.0005와 5.5가 동일하고 5.5 < 5.0006이 됩니다.이로 인해 사용자가 혼란스러워질 수 있습니다.스트링 매칭툴은 특정 버전 번호를 찾지 못할 수 있습니다.또한 프로그래머가 버전 번호 인덱스 해시 테이블 등의 문자열 인덱스화된 데이터 구조를 사용하면 패키지 관리에 미묘한 버그가 발생할 수 있습니다.

정렬을 쉽게 하기 위해 일부 소프트웨어 패키지는 major.minor.release 체계의 각 구성 요소를 고정된 너비로 나타냅니다.Perl은 버전 번호를 부동소수점 번호로 나타냅니다.예를 들어 Perl의 5.8.7 릴리스는 5.008007로 나타낼 수도 있습니다.이를 통해 5.8.10의 이론 버전을 5.008010으로 나타낼 수 있습니다.그 외의 소프트웨어 패키지에서는, 각 세그먼트를 고정 비트폭으로 패키지 하고 있습니다.예를 들어 Microsoft Windows 의 경우, 버전 번호 6.3.9600.16384 는 16 진수 0x0006000325804000 으로 표시됩니다.버전 번호의 세그먼트(segment)가 999를 넘으면 부동소수점 방식이 분해됩니다.각각 16비트를 사용하는 패킹 바이너리 방식은 65535 이후에 분해됩니다.

버전 번호의 정치적, 문화적 중요성

마일스톤으로서의 버전 1.0

자유 소프트웨어 커뮤니티와 오픈 소스 커뮤니티는 소프트웨어를 조기에, 그리고 자주 출시하는 경향이 있습니다.초기 버전은 1보다 작은 수치입니다.이 0.x 버전은 소프트웨어가 불완전하고 일반 릴리스에 충분한 신뢰성이 없으며 현재 상태에서 사용할 수 있음을 나타내기 위해 사용됩니다.이전 버전과 호환되지 않는 변경은 0.x 버전에서 흔히 볼 수 있습니다.버전 1.0은 주요 마일스톤으로 사용되며 소프트웨어에는 개발자가 해당 버전에 도입하고자 하는 주요 기능과 기능이 모두 포함되어 있으며 일반 [35][36]릴리스에 충분한 신뢰성이 있는 것으로 간주됩니다.그 좋은 예가 Linux 커널입니다.[47]이 커널은 1991년에 버전 0.01로 처음 출시되어 버전 1.0.[48]0에 도달하는 데 1994년까지 걸렸습니다.

아케이드 게임 에뮬레이터 MAME의 개발자들은 에뮬레이트할 아케이드 게임들이 항상 더 많이 있을 것이고 따라서 이 프로젝트는 결코 진정으로 완성될 수 없기 때문에 이 프로그램의 버전 1.0을 출시할 의도가 없다.따라서 버전 0.99에 이어 버전 0.100이 [49]뒤를 이었습니다.

인터넷이 보급된 이후 대부분의 상용 소프트웨어 벤더는 메이저버전을 '완전'으로 만들어야 한다는 상식을 따르지 않고 해결 방법이 발견되어 수정할 [citation needed]수 있는 기존의 문제를 해결하기 위해 버그 수정 패치를 사용합니다.

마케팅용 버전 번호

비교적 일반적인 방법은 마케팅상의 이유로 버전 번호를 대폭 올리는 것입니다.소프트웨어 벤더는 1.0 릴리스를 건너뛰거나 후속 버전 번호를 붙여 신속하게 릴리스를 출시하는 경우가 있습니다.이는 1.0 소프트웨어가 실제 가동 [citation needed]환경에 대한 신뢰도가 너무 낮다고 많은 고객이 생각하기 때문입니다.예를 들어, dBase II의 경우와 같이 제품은 버전 번호로 출시되며, 버전 번호는 제품보다 더 성숙하다는 것을 의미합니다.

다른 경우 버전 번호가 경쟁사의 버전과 일치하도록 증가합니다.이는 Microsoft, America Online, Sun Solaris, Java Virtual Machine, SCO Unix, WordPerfect에 의한 제품 버전 번호 부여의 많은 예에서 볼 수 있습니다.Microsoft Access는 Microsoft Word 버전 번호와 일치하도록 버전 2.0에서 버전 7.0으로 점프했습니다.

또한 Microsoft는 Netscape 브라우저가 Microsoft의 Internet Explorer에 맞춰 버전 5~6을 건너뛰는 '캐치업' 버전 관리의 대상이 되어 왔습니다.또한 1.0 이전 개발 과정에서 Mozilla 응용 프로그램 스위트가 사용자 에이전트 문자열에서 버전 5를 상속받았고 Netscape 6.x가 Mozilla의 코드 기반에 구축되었기 때문입니다.

경쟁사에 뒤지지 않는 또 다른 예는 1999년 Slackware Linux가 버전 4에서 버전 7로 뛰어올랐을 때입니다.[50]

미신

  • Microsoft Office 의 Office 2007 릴리스의 내부 버전 번호는 12 입니다.다음 버전인 Office 2010은 숫자 [51]13을 둘러싼 미신 때문에 내부 버전 14를 가지고 있다.Visual Studio 2013은 제품의 버전 번호 12.0이며, 새로운 버전인 Visual Studio 2015도 같은 이유로 버전 번호 14.0을 가집니다.
  • Roxio Toast는 숫자 13을 둘러싼 미신을 건너뛰기 위해 버전 12에서 버전 14로 변경되었다.
  • 코렐의 WordPerfect Office 버전 13은 X3(로마 번호 10과 3)로 판매되고 있습니다.이 절차는 다음 버전인 X4까지 계속되었습니다.Corel의 Graphic Suite(즉, CorelDRAW, Corel Photo-Paint)와 비디오 편집 소프트웨어인 "Video Studio"에서도 같은 일이 발생했습니다.
  • Sybase는 Adaptive Server Enterprise 관계형 데이터베이스 제품에서 주요 버전 13 및 14를 건너뛰어 12.5에서 15.0으로 전환했습니다.
  • ABBYY Lingvo 사전은 12, x3(14) 및 x5(15) 번호를 사용합니다.
  • SUSE Linux Enterprise는 버전 12 이후 버전 13과 14를 건너뛰고 2018년 7월에 SLES 15를 직접 출시했습니다.

기크 문화

  • SUSE Linux 배포는 버전 4.2에서 시작되었으며, 42를 참조하기 위해 더글러스 애덤스의 갤럭시 히치하이커 가이드에서 언급된 "생명, 우주 및 모든 것에 대한 궁극적인 질문에 대한 대답"을 참조했습니다.
  • 리트를 참조하는 Slackware Linux 디스트리뷰션은 버전 13.37이었습니다.
  • Finnix는 버전 93.0에서 100으로 건너뛰어 Windows [52]95에 대한 언급인 "There Will Be No Finnix '95"라는 주장을 충족시키기도 했습니다.
  • Tagged Image File Format 사양은 시작부터 내부 버전 번호로서 42를 사용해 왔습니다.이 사양의 설계자는 개발 지시와 상충하기 때문에 라이프 타임 동안 더 이상 변경할 필요가 없습니다.

인식된 마케팅 어려움 극복

1990년대 중반 급속히 성장한 CMMS 막시모는 맥시모 시리즈 3에서 시리즈 5로 직접 옮겨갔고, 숫자 4가 "죽음"과 관련이 있는 중국 시장에서 그 숫자의 마케팅 어려움으로 인해 시리즈 4를 건너뛰었다(사포비아 참조).그러나 이것이 맥시모 시리즈 5 버전 4.0의 출시를 막지는 못했다.(그 후 시리즈버전 1.0 출시 후 '시리즈'버전 번호가 사실상 리셋됩니다).

중요성

소프트웨어 엔지니어링 분야

버전 번호는 소프트웨어 제품의 복사본을 식별하거나 개발자에 의해 출시된 최신 버전 등 다른 복사본과 비교하기 위해 소비자 또는 클라이언트가 실제로 사용합니다.프로그래머나 회사에 있어서 버전 관리는 리비전별로 사용되는 경우가 많습니다.이 경우 소프트웨어의 개별 부분을 동일한 부분의 최신 또는 오래된 리비전(종종 공동 버전 관리 시스템)과 비교 및 대조합니다.

21세기에는 더 많은 프로그래머들이 시맨틱 버전 [1]관리 정책과 같은 정형화된 버전 정책을 사용하기 시작했다.이러한 정책의 목적은 다른 프로그래머가 코드 변경으로 인해 자신이 작성한 내용이 파손될 가능성이 있는 시기를 쉽게 알 수 있도록 하는 것입니다.이러한 정책은 소프트웨어 라이브러리 및 프레임워크에 특히 중요하지만 명령줄 애플리케이션(다른 애플리케이션에서 호출할 수 있음) 및 기타 애플리케이션(서드파티에 의해 스크립트 작성 및/또는 확장 가능)에도 매우 유용할 수 있습니다.

버전 관리는 소프트웨어 패치 적용 및 업그레이드의 많은 스킴을 유효하게 하기 위해서도 필요합니다.특히 업그레이드 대상과 장소를 자동으로 결정합니다.

기술 지원

버전 번호를 사용하면 사용자가 실행하고 있는 코드를 정확하게 확인할 수 있으므로 문제의 원인으로 이미 수정된 버그 등을 배제할 수 있습니다.이것은 프로그램에 상당한 사용자 커뮤니티가 있는 경우, 특히 기술 지원을 제공하는 사람이 코드를 작성한 사람이 아닐 정도로 그 커뮤니티가 충분히 큰 경우 특히 중요합니다.version.revision.change 스타일 넘버링의 의미도[1] IT 스탭에게 중요합니다.스탭은, 새로운 릴리스를 시설에 도입하기 전에, 그 릴리스에 얼마나 많은 주의와 조사를 실시할 필요가 있는지를 결정하기 위해서, 이 번호를 자주 사용합니다.경험의 법칙으로, 변화가 클수록 무언가가 부서질 가능성이 커집니다(Changelog를 조사하면 표면적이거나 무관한 변화만 드러날 수 있습니다).이것이 Asterisk 등이 채택한 'drop the major release' 접근법에 대한 거부감의 한 가지 이유입니다.이러한 접근법에서는 스태프는 모든 업데이트에 대해 완전한 회귀 테스트를 실시해야 합니다(또는 적어도 실시해야 합니다).

소프트웨어 외부에서 사용

OpenVMS 파일 시스템과 같은 일부 컴퓨터 파일 시스템도 파일 버전을 유지합니다.문서 간의 버전 관리는 컴퓨터 및 소프트웨어 엔지니어링에서 사용되는 루틴과 비교적 유사합니다.여기서 구조, 내용 또는 조건이 조금씩 변경될 때마다 버전 번호가 1씩 증가하거나 더 작거나 더 큰 값으로 증가합니다.또한 작성자의 개인적 선호도, 변경의 크기 또는 중요도에 따라 달라집니다.만든.

소프트웨어 스타일의 버전 번호는 다른 미디어에서 찾을 수 있습니다.

경우에 따라서는 그 용도가 직접 유사하다(예를 들어 Jackass 2.5, 특별한 기능이 추가된 Jackass Number Two 버전, 버전 2.0이라는 제목의 Garbage의 두 번째 앨범, 3번째 에디션부터 규칙이 개정되었지만 4번째 에디션으로 간주되지는 않았다).

하이테크놀로지 관련 어소시에이션에서 사용되는 경우가 많고, 말 그대로 「버전」을 나타내는 것은 아닙니다(예를 들면, 영화 Tron의 후속 비디오 게임인 Tron 2.0이나, 2번째 시즌을 버전 2.0이라고 하는 텔레비전 시리즈인 The IT Crowd).특히 주목할 만한 용도는 Web 2.0입니다.Web 2.0은 사용자가 작성한 콘텐츠, 조작성 및 상호 운용성을 중시하는 2000년대 초반의 웹 사이트를 말합니다.

「 」를 참조해 주세요.

메모들

  1. ^ 클래식한 Mac OS 버전(패치는 포함되지 않음)의 전체 순서는 1.0, 1.1, 2.0, 3.2(건너뛰기 3.1), 4.0, 4.1, 5.0, 5.1, 6.0, 7.0, 7.1, 7.5, 7.6, 8.0, 8.1, 8.5j입니다.

레퍼런스

  1. ^ a b c d e f Preston-Werner, Tom (2013).시멘틱 버전 2.0.0크리에이티브 커먼즈https://semver.org/spec/v2.0.0.html 에서 취득했습니다.
  2. ^ TENEX, PDP - 10, Bobrow, Burchfiel, Murphy, Tomlinson, 1972년 3월, ACM 15(3):135-143의 페이지별 시간 공유 시스템.
  3. ^ 패키지 상호의존성, Robert Sanders, 1994-02-25.
  4. ^ [<https://lists.debian.org/debian-devel/1995/07/msg00085.html Bug#1167: ELF 개발 패키지가 실패하거나 의존관계가 없습니다], Ian Jackson, 1995-07-30.
  5. ^ 데비안의 역사, 하비에르 페르난데스-산기노 외, 2021-10-26.
  6. ^ Lam, Patrick; Dietrich, Jens; Pearce, David J. (August 16, 2020). "Putting the Semantics into Semantic Versioning". arXiv:2008.07069 [cs.SE].
  7. ^ "Library Interface Versioning in Solaris and Linux".
  8. ^ "Libtool's versioning system". Libtool documentation.
  9. ^ "Versioning Numbering Concepts – The Apache Portable Runtime Project". Retrieved April 11, 2009.
  10. ^ "Daemonite: The science of version numbering". September 14, 2004. Retrieved April 11, 2009.
  11. ^ 프랭크 카인, 버트 드 비어, 루이스 마르티네즈, 해리엇 모릴, 미하 페트릭, 데이비드 비거스, 수지 웬들러"System z Parallel Sysplex Best Practices", 2011. 페이지 6.
  12. ^ "Opera Changelogs for Windows". Opera Software. 2014. Retrieved November 6, 2014.
  13. ^ "Home". Movable Type Documentation Wiki. June 25, 2013. Retrieved November 6, 2014.
  14. ^ "GNU Coding Standards: Releases". GNU Project. May 13, 2014. Retrieved May 25, 2014. You should identify each release with a pair of version numbers, a major version and a minor. We have no objection to using more than two numbers, but it is very unlikely that you really need them.
  15. ^ a b "Advogato: Version numbering madness". February 28, 2000. Retrieved April 11, 2009.
  16. ^ Debian 정책 매뉴얼, 5.6.12 버전
  17. ^ "Java Edition version history". Official Minecraft Wiki. Retrieved March 6, 2019.
  18. ^ "Calendar Versioning — CalVer". calver.org. Retrieved October 10, 2019.
  19. ^ Markus Kuhn (December 19, 2004). "International standard date and time notation". University of Cambridge. Retrieved April 11, 2009.
  20. ^ Jeff Atwood (February 15, 2007). "Coding Horror: What's In a Version Number, Anyway?". Retrieved November 15, 2016.
  21. ^ "PEP 440 – Version Identification and Dependency Specification".
  22. ^ 도널드 E. 크누스TeX와 메타폰트의 미래, NTG 저널 MAPS(1990), 489.디지털 타이포그래피 30장으로 전재, 571페이지.
  23. ^ "Apple Releases macOS 10.13.3 Supplemental Update With Telugu Crash Fix". Retrieved March 26, 2018.
  24. ^ Gallagher, William (June 22, 2020). "Apple turns macOS up to 11 – or to 10.16". AppleInsider.
  25. ^ Heater, Brian. "Apple unveils macOS 11.0 Big Sur". TechCrunch. Archived from the original on June 22, 2020. Retrieved June 22, 2020.
  26. ^ De Looper, Christian (October 12, 2021). "Apple macOS Monterey: Everything we know so far". BGR. Archived from the original on October 12, 2021.
  27. ^ "Announcing Windows 10".
  28. ^ "Windows 11: A new era for the PC begins today". Windows Blogs. October 4, 2021.
  29. ^ "Debian FAQ: 6.2.2 Where do these codenames come from?". Archived from the original on January 2, 2021. Retrieved January 2, 2021.
  30. ^ "BLAG Linux And GNU". DistroWatch.com. Retrieved September 29, 2011.
  31. ^ "News and Updates: BLAG". DistroWatch.com. Retrieved September 29, 2011.
  32. ^ "blag download". blag. Retrieved September 29, 2011.
  33. ^ "Kelvin Versioning · jtobin.io". jtobin.io. Retrieved March 17, 2021.
  34. ^ urbit.org. "Toward a Frozen Operating System – Urbit". urbit.org. Retrieved March 17, 2021.
  35. ^ a b "ToaruOS 1.0 Open Source OS Released After 6+ Years Of Development". February 13, 2017. Retrieved May 23, 2017.
  36. ^ a b Gilbertson, Scott. "Wine Headed For a 1.0 Release. Finally". Wired. Retrieved May 23, 2017.
  37. ^ "Firefox Release Calendar – MozillaWiki". wiki.mozilla.org.
  38. ^ "Simultaneous Release – Eclipsepedia". wiki.eclipse.org.
  39. ^ "ReleasePlan – The Document Foundation Wiki". wiki.documentfoundation.org.
  40. ^ "Releases – Ubuntu Wiki". wiki.ubuntu.com.
  41. ^ "Releases – Fedora Project Wiki". fedoraproject.org.
  42. ^ "PEP 0 – Index of Python Enhancement Proposals (PEPs)". Python.org.
  43. ^ "Release Plan". digikam.org. March 25, 2018.
  44. ^ "VMware Product Release Tracker (vTracker)". Virten.net. February 13, 2015.
  45. ^ "Node.js is SemVer". The NodeSource Blog – Node.js Tutorials, Guides, and Updates. September 15, 2015. introduced Node with a Linux kernel-style odd/even versioning scheme. Retrieved March 26, 2018.
  46. ^ Kevin P. Fleming (July 21, 2011). "The Evolution of Asterisk (or: How We Arrived at Asterisk 10) Inside the Asterisk". Digium, Inc. Retrieved May 25, 2014.
  47. ^ 토발즈, 라이너스:Linux 릴리스 0.01에 관한 주의사항 kernel.org, 1991.
  48. ^ Calore, Michael (August 25, 2009). "Aug. 25, 1991: Kid From Helsinki Foments Linux Revolution". WIRED. Retrieved February 8, 2018.
  49. ^ Still, Michael; Smith, Stewart (December 15, 2007). Practical MythTV: Building a PVR and Media Center PC. New York: Springer-Verlag New York, Inc. p. 9. ISBN 978-1-59059-779-8. Retrieved April 15, 2018.
  50. ^ "Slackware FAQ".
  51. ^ Paul Thurrott (May 14, 2009). "Office 2010 FAQ". Archived from the original on April 19, 2009. Retrieved December 30, 2009.
  52. ^ Finnie, Ryan (October 23, 2010). "I'm sorry". Retrieved February 9, 2012.

외부 링크