버전의 숫자는 일반적으로 무엇을 나타 냅니까 (예 : v1.9.0.1)?

어쩌면 이것은 어리석은 질문이지만, 항상 소프트웨어의 단일 구성 요소를 나타내는 기간으로 표시된 각 숫자를 가정했습니다. 그것이 사실이라면, 그들은 다른 것을 대표 하는가? 소프트웨어의 다른 빌드에 버전을 할당하고 싶지만 어떻게 구성해야하는지 잘 모르겠습니다. 내 소프트웨어에는 5 개의 개별 구성 요소가 있습니다.

버전 1.9.0.1에서 :

• 1 : 주요 개정 (새로운 UI, 많은 새로운 기능, 개념 변경 등)

• 9 : 사소한 수정 (검색 창 변경, 기능 추가 1 개, 버그 수정 모음)

• 0 : 버그 수정 릴리스

• 1 : 빌드 번호 (사용 된 경우)-2.0.4.2709와 같은 것을 사용하여 .NET 프레임 워크를 보는 이유

4 개 수준으로 내려가는 앱은 많지 않으며 일반적으로 3이면 충분합니다.

있다 시맨틱 버전 사양

다음은 버전 2.0.0의 요약입니다.

버전 번호 MAJOR.MINOR.PATCH가 주어지면 다음을 증가 시키십시오.

1. 호환되지 않는 API 변경을 할 때 주요 버전,
2. 이전 버전과 호환되는 방식으로 기능을 추가 할 때 마이너 버전
3. 이전 버전과 호환되는 버그 수정을 할 때 PATCH 버전.

시험판 및 빌드 메타 데이터에 대한 추가 레이블은 MAJOR.MINOR.PATCH 형식의 확장으로 제공됩니다.

매우 임의적 일 수 있으며 제품마다 다릅니다. 예를 들어, 우분투 배포판에서 8.04는 2008을 나타냅니다.

일반적으로 가장 왼쪽 (주) 숫자는 주요 릴리스를 나타내며 오른쪽으로 갈수록 변경이 적습니다.

major.minor [.maintenance [.build]]

http://en.wikipedia.org/wiki/Software_versioning#Numeric

포인트가 많을수록 릴리즈가 더 작습니다. 그 이상의 확실한 표준은 없습니다. 프로젝트 관리자가 결정한 내용에 따라 다른 것을 의미 할 수 있습니다.

예를 들어 워드 프레스는 다음과 같은 라인을 따릅니다.

1.6-> 2.0-> 2.0.1-> 2.0.2-> 2.1-> 2.1.1-> 2.2 ...

1.6-2.0은 기능, 인터페이스 변경, API의 주요 변경 사항, 일부 1.6 템플릿 및 플러그인의 손상 등과 같은 큰 릴리스입니다. 2.0-2.0.1은 사소한 릴리스 일 것입니다. 아마도 보안 버그를 수정했을 것입니다. 2.0.2 ~ 2.1은 중요한 릴리스입니다. 일반적으로 새로운 기능입니다.

숫자는 다른 답변에서 설명한 것처럼 유용 할 수 있지만 어떻게 의미가 없는지 고려하십시오 ... Sun, 당신은 SUN, java를 알고 있습니다 : 1.2, 1.3, 1.4 1.5 또는 5 then 6. 오래된 Apple II 버전 번호 어떤 것. 요즘 사람들은 버전 번호를 포기하고 "Feisty fig"(또는 그와 비슷한 것)와 "hardy heron"과 "europa"와 "ganymede"와 같은 어리석은 이름으로 가고 있습니다. 물론 이것은 프로그램 변경을 중단하기 전에 목성의 달이 떨어지고 명확한 순서가 없기 때문에 어느 것이 더 최신인지 알 수 없기 때문에 이것은 훨씬 덜 유용합니다.

버전 v1.9.0.1에서 : 이름을 사용하거나 와 같은 빌드를 원하지 않을 때 사용되는 명시 적 버전 관리 체계 입니다.

1 : 하위 호환성을 손상시킬 수있는 주요 버전

9 : 이전 버전과의 호환성과 함께 앱을 지원하는 새로운 기능 추가.

0 : 일부 사소한 버그 수정

1 : 빌드 번호 (시험판 번호)

그러나 요즘에는 이러한 버전 관리 체계를 찾을 수 없습니다. 시맨틱 버전 관리 [semver2.0] https://semver.org/

버전 번호는 일반적으로 별도의 구성 요소를 나타내지 않습니다. 일부 사람 / 소프트웨어의 경우 숫자는 상당히 임의적입니다. 다른 사람들에게는 버전 번호 문자열의 다른 부분이 다른 것을 나타냅니다. 예를 들어, 일부 시스템은 파일 형식이 변경 될 때 버전 번호의 일부를 증가시킵니다. 따라서 V 1.2.1은 다른 모든 V 1.2 버전 (1.2.2, 1.2.3 등)과 호환되는 파일 형식이지만 V 1.3과는 호환되지 않습니다. 궁극적으로 어떤 체계를 사용하고 싶은지는 당신에게 달려 있습니다.

일반적으로

MajorVersion.MinorVersion.Revision.Build

의존하지만 전형적인 표현은 major.minor.release.build입니다. 입니다.

어디:

• 주요한 는 소프트웨어의 주요 릴리스 버전입니다. .NET 3.x를 생각하십시오.
• minor 는 소프트웨어의 부 릴리스 버전입니다. .NET x.5를 생각하십시오
• release 는 해당 버전의 릴리스이며 일반적으로 bugfix는
• build 는 수행 한 빌드 수를 나타내는 숫자입니다.

예를 들어 1.9.0.1은 1.8 및 1.7 등의 소프트웨어 버전 1.9입니다. 1.7, 1.8 및 1.9는 일반적으로 버그 수정과 함께 소량의 새로운 기능을 추가합니다. xx0.x이므로 1.9의 초기 릴리스이며 해당 버전의 첫 번째 빌드입니다.

또한 해당 주제 에 대한 Wikipedia 기사에서 유용한 정보를 찾을 수 있습니다 .

소령 버그

(또는 그것에 약간의 변형)

버그는 일반적으로 새로운 기능이없는 버그 수정입니다.

사소한 변경 사항은 새로운 기능을 추가하지만 주요 방식으로 프로그램을 변경하지는 않습니다.

주요 기능은 이전 기능을 손상 시키거나 사용자가 프로그램 사용 방법을 변경하기에 너무 큰 프로그램 변경입니다.

모든 사람은이 숫자로하고 싶은 것을 선택합니다. 어쨌든 어리석기 때문에 릴리스 abc를 호출하려는 유혹을 받았습니다. 즉, 지난 25 년 이상의 개발 기간 동안 제가 본 것은 이런 방식으로 작동하는 경향이 있습니다. 버전 번호가 1.2.3이라고 가정 해 봅시다.

"1"은 "주"개정을 나타냅니다. 일반적으로 이것은 초기 릴리스, 대규모 기능 세트 변경 또는 코드의 상당 부분을 다시 작성하는 것입니다. 기능 세트가 결정되고 적어도 부분적으로 구현되면 다음 번호로 이동합니다.

"2"는 시리즈 내 릴리스를 나타냅니다. 우리는 종종이 위치를 사용하여 마지막 주요 릴리스에서 만들지 않은 기능을 따라 잡습니다. 이 위치 (2)는 대개 버그 수정과 함께 기능 추가를 나타냅니다.

대부분의 상점에서 "3"은 패치 릴리스 / 버그 수정을 나타냅니다. 적어도 상업적인 측면에서는 이것이 중요한 기능 추가를 나타내지 않습니다. 기능이 위치 3에 표시되면 버그 수정 릴리스를 수행해야한다는 것을 알기 전에 누군가가 무언가를 체크인했기 때문일 수 있습니다.

"3"위치를 넘어서? 왜 사람들이 그런 종류의 일을하는지 실마리가 없습니다. 더 혼란스러워집니다.

특히 OSS 중 일부는이 모든 것을 엉망으로 만듭니다. 예를 들어 Trac 버전 10은 실제로 0.10입니다 .XX OSS 세계의 많은 사람들은 자신감이 부족하거나 주요 릴리스가 완료되었다고 발표하고 싶지 않다고 생각합니다.

C # AssemblyInfo.cs 파일에서 다음을 볼 수 있습니다.

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
/ You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]

release.major.minor.revision이 제 추측 일 것입니다.
그러나 제품마다 크게 다를 수 있습니다.

메이저 포인트 마이너 빌드. 메이저와 마이너는 자명하며, 포인트는 몇 가지 사소한 버그 수정을위한 릴리스이며 빌드는 단지 빌드 식별자입니다.

예. 주요 릴리스에는 새롭고 큰 기능이 추가되거나 호환성이 손상되거나 종속성이 크게 다를 수 있습니다.

마이너 릴리스는 기능을 추가하지만, 베타 메이저 릴리스에서 제거 된 포팅 된 버전은 더 작습니다.

세 번째 버전 번호 구성 요소가있는 경우 일반적으로 중요한 버그 수정 및 보안 수정입니다. 더 많은 것이 있으면 실제로 제품에 너무 의존하여 일반적인 대답을하기가 어렵습니다.

주요 release.minor release.bug 수정의 패러다임은 꽤 일반적입니다.

일부 엔터프라이즈 지원 계약에는 특정 릴리스 지정 방법과 관련된 $$$ (또는 계약 책임 위반)가 있습니다. 예를 들어, 계약은 일정 기간 동안 고객에게 몇 가지 주요 릴리스를 부여 할 수 있거나 한 기간 동안 x 릴리스 미만의 마이너 릴리스가 있거나 계속해서 많은 지원을받을 수 있다고 약속 할 수 있습니다 릴리스. 물론 주 릴리스가 부 릴리스와 비교하여 주 릴리스가 무엇인지 설명하기 위해 계약서에 단어를 몇 개나 입력하더라도 항상 주관적이며 항상 회색 영역이 생겨 소프트웨어 공급 업체가 시스템을 게임 할 수있는 가능성이 있습니다. 그러한 계약 조항을 이겼다.

사람들은 2.1, 2.0.1 또는 2.10과 같은 버전 번호의 미묘한 차이를 항상 인식하지는 못합니다. 기술 지원 담당자에게 문제가 발생한 횟수를 문의하십시오. 개발자는 세부적인 지향과 계층 구조에 익숙하므로 이는 우리에게 맹점입니다.

가능하면 고객에게 더 간단한 버전 번호를 공개하십시오.

라이브러리의 경우 버전 번호는 두 릴리스 간의 호환성 수준 과 업그레이드가 얼마나 어려운지 알려줍니다.

버그 수정 릴리스는 이진, 소스 및 직렬화 호환성을 유지해야합니다.

마이너 릴리스는 프로젝트마다 다른 의미를 갖지만 일반적으로 소스 호환성을 유지할 필요는 없습니다.

주요 버전 번호는 세 가지 형식을 모두 깰 수 있습니다.

나는 이론적 근거에 대한 자세한 내용을 썼다 여기 .

메이저, 마이너, 패치, 빌드, 보안 패치 등의 조합

처음 두 가지는 메이저 및 마이너입니다. 나머지는 프로젝트, 회사 및 때로는 커뮤니티에 따라 다릅니다. OS의 FreeBSD와 마찬가지로 보안 패치를 나타내는 1.9.0.1_number가 있습니다.

언어에 따라 약간 다릅니다. 예를 들어 Delphi와 C #은 다른 의미를 갖습니다.

일반적으로 처음 두 숫자는 주 버전과 부 버전을 나타냅니다 (예 : 첫 번째 실제 릴리스의 경우 1.0, 일부 중요한 버그 수정 및 부의 새로운 기능의 경우 1.1, 큰 새 기능 릴리스의 경우 2.0).

세 번째 숫자는 "정말 부"버전 또는 개정을 나타낼 수 있습니다. 1.0.1은 예를 들어 1.0.0에 대한 매우 작은 버그 수정입니다. 그러나 소스 제어 시스템의 개정 번호 또는 모든 빌드마다 증가하는 계속 증가하는 번호를 전달할 수도 있습니다. 또는 날짜 스탬프입니다.

조금 더 자세히 여기에 . "공식적으로", .net에서 4 개의 숫자는 "Major.Minor.Build.Revision"이고 델파이에는 "Major.Minor.Release.Build"가 있습니다. 버전 관리에 "Major.Minor.ReallyMinor.SubversionRev"를 사용합니다.

일반적으로 숫자는 개별 내부 구성 요소가 아닌 version.major.minor.hotfix 형식입니다. 따라서 v1.9.0.1은 버전 1, 주 릴리스 9 (v1), 부 릴리스 (v1.9) 0, 핫픽스 1 (v1.9.0)입니다.

첫 번째 숫자는 일반적으로 주 버전 번호라고합니다. 기본적으로 빌드간에 중요한 변경 사항을 나타내는 데 사용됩니다 (예 : 많은 새로운 기능을 추가 할 때 주 버전을 증가시킵니다). 동일한 제품의 주요 버전이 다른 구성 요소는 호환되지 않을 수 있습니다.

다음 숫자는 부 버전 번호입니다. 새로운 기능이나 많은 버그 수정 또는 작은 아키텍처 변경을 나타낼 수 있습니다. 부 버전 번호가 다른 동일한 제품의 구성 요소는 함께 작동하거나 작동하지 않을 수 있습니다.

다음은 일반적으로 빌드 번호라고합니다. 이것은 매일 또는 각 "릴리스 된"빌드 또는 각 빌드와 함께 증분 될 수 있습니다. 빌드 번호 만 다르고 일반적으로 함께 작동하는 두 구성 요소 간에는 약간의 차이 만있을 수 있습니다.

최종 번호는 일반적으로 개정 번호입니다. 종종 이것은 자동 빌드 프로세스에서 사용되거나 테스트를 위해 "일회용"일회용 빌드를 만드는 경우에 사용됩니다.

증분 할 때 버전 번호는 귀하에게 달려 있지만 항상 증분 하거나 동일하게 유지 해야합니다 . 모든 구성 요소가 동일한 버전 번호를 공유하도록하거나 변경된 구성 요소의 버전 번호 만 증가시킬 수 있습니다.

복잡한 소프트웨어의 버전 번호는 전체 패키지를 나타내며 부품의 버전 번호와 무관합니다. Gizmo 버전 3.2.5에는 Foo 버전 1.2.0 및 Bar 버전 9.5.4가 포함될 수 있습니다.

버전 번호를 만들 때 다음과 같이 사용하십시오.

1. 첫 번째 번호는 주요 릴리스입니다. 사용자 인터페이스를 크게 변경하거나 기존 인터페이스를 중단해야하는 경우 (사용자가 인터페이스 코드를 변경해야 함) 새 기본 버전으로 이동해야합니다.

2. 두 번째 숫자는 새로운 기능이 추가되었거나 내부적으로 다르게 작동 함을 나타냅니다. 예를 들어, Oracle 데이터베이스는 데이터 검색에 다른 전략을 사용하여 대부분의 작업을 더 빠르고 일부 작업을 더 느리게 할 수 있습니다. 기존 인터페이스는 계속 작동해야하며 사용자 인터페이스를 인식 할 수 있어야합니다.

3. 버전 번호는 소프트웨어를 작성하는 사람에게 달려 있습니다. Oracle은 5 개의 그룹을 사용합니다. Oracle 버전은 10.1.3.0.5와 같습니다. 세 번째 그룹부터는 버그 수정 또는 기능의 약간의 변경 만 소개해야합니다.

major.minor의 경우 덜 변하는 것은 처음 두 개이며, 그 후에는 빌드, 개정, 릴리스에서 모든 사용자 정의 알고리즘 (예 : 일부 MS 제품)에 이르기까지 다양합니다.

모든 조직 / 그룹에는 자체 표준이 있습니다. 중요한 것은 당신이 선택하는 표기법을 고수한다는 점입니다. 그렇지 않으면 고객이 혼란 스러울 것입니다. 내가 일반적으로 3 개의 숫자를 사용했다고 말했습니다.

x.yz.bbbbb. 여기서 : x :는 주 버전 (주요 새로운 기능)입니다. y :는 부 버전 번호입니다 (작은 새로운 기능, UI 변경이없는 작은 개선 사항). z : 서비스 팩입니다 (기본적으로 xy와 동일하지만 일부 버그 수정이 포함됨) bbbb : 는 빌드 번호이며 "정보 상자"에서만 고객 지원을위한 기타 세부 정보가 표시됩니다. bbbb는 무료 형식이며 모든 제품이 자체적으로 사용할 수 있습니다.

우리가 사용하는 것은 다음과 같습니다.

1. 첫 번째 숫자 = 전체 시스템 시대 2 년마다 변경되며 일반적으로 기술 또는 클라이언트 기능 또는 둘 다의 근본적인 변경을 나타냅니다.
2. 두 번째 숫자 = 데이터베이스 스키마 개정. 이 수를 늘리려면 데이터베이스 마이그레이션이 필요하고 시스템도 크게 변경됩니다 (또는 시스템이 복제되어 데이터베이스 구조를 변경하려면 신중한 업그레이드 프로세스가 필요합니다). 첫 번째 숫자가 변경되면 0으로 재설정합니다.
3. 세 번째 숫자 = 소프트웨어 만 변경됩니다. 데이터베이스 스키마가 변경되지 않으므로 일반적으로 클라이언트별로 클라이언트에서 구현할 수 있습니다. 두 번째 숫자가 변경되면 0으로 재설정됩니다.
4. Subversion 버전 번호 TortoiseSVN 도구를 사용하여 빌드시이를 자동으로 채 웁니다. 이 숫자는 재설정되지 않지만 지속적으로 증가합니다. 이를 사용하면 언제든지 모든 버전을 다시 만들 수 있습니다.

모든 사람이 명확하고 중요한 기능을 가지고 있기 때문에이 시스템은 우리에게 잘 봉사하고 있습니다. 나는 다른 팀이 주요 숫자 / 부 숫자 질문 (얼마나 큰 변화가 큰지)으로 어려움을 겪는 것을 보았고 그 이점을 보지 못했습니다. 데이터베이스 개정을 추적 할 필요가없는 경우 3 또는 2 자리 버전 번호로 이동하여보다 쉽게 ​​생활하십시오!

버전 : v1.9.0.1

어디-

. v는 버전의 약어입니다. 조직마다 채택 된 명명법에 따라 회사마다 다릅니다. 1.9.0.1과 같은 일부 조직에서는 침묵 할 수 있습니다.

. 1은 주요 버전을 나타내며 응용 프로그램 스택, 인프라 (플랫폼) 또는 노출 된 네트워크 인터페이스의 아키텍처 수정시 업데이트됩니다.

. 9는 마이너를 포함하고 ui, api, database 등과 같은 새로운 구성 요소를 추가하는 것과 같은 활동에 업데이트됩니다. 특정 아키텍처에서

. 0은 기능을 나타내며 기존 구성 요소 (ui, api, 데이터베이스 등)의 개선 사항에 따라 업데이트됩니다

. 1은 모든 단계 메이저, 마이너 및 기능에서 빌드 카운터를 나타냅니다. 또한 프로덕션 릴리스 후 핫픽스도 포함합니다.