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

https://stackoverflow.com/questions/65718

versions

09-06-2019
|

문제

어쩌면 이것은 어리석은 질문일지도 모르지만, 나는 항상 마침표로 표시된 각 숫자가 소프트웨어의 단일 구성 요소를 나타낸다고 가정해 왔습니다.그것이 사실이라면, 그것들이 다른 것을 대표한 적이 있습니까?내 소프트웨어의 다양한 빌드에 버전을 할당하고 싶지만 어떻게 구성되어야 하는지 잘 모르겠습니다.내 소프트웨어에는 다섯 가지 구성 요소가 있습니다.

해결책

버전에서 1.9.0.1:

1:주요 개정(새로운 UI, 새로운 기능 다수, 개념 변경 등)
9:사소한 개정(검색 상자 변경, 기능 1개 추가, 버그 수정 모음)
0:버그 수정 릴리스
1:빌드 번호(사용된 경우) - 2.0.4.2709와 같은 것을 사용하는 .NET 프레임워크를 볼 수 있는 이유입니다.

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

다른 팁

거기에는 의미적 버전 관리 사양

버전 2.0의 요약은 다음과 같습니다.

버전 번호 MAJOR.MINOR.PATCH가 주어지면 다음을 증가시킵니다.
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
프리 릴리스 및 빌드 메타 데이터를위한 추가 레이블은 major.minor.patch 형식의 확장으로 제공됩니다.

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

일반적으로 가장 왼쪽(주요) 숫자는 주요 릴리스를 나타내고, 오른쪽으로 갈수록 관련된 변경 사항이 작아집니다.

major.minor[.maintenance[.build]]

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

숫자는 다른 답변에서 설명하는 것처럼 유용할 수 있지만 의미가 없을 수도 있다는 점을 고려하세요.Sun, SUN, java를 아시죠?1.2, 1.3, 1.4 1.5 또는 5, 그 다음 6.오래된 Apple II 버전 번호에서는 무언가를 의미했습니다.요즘 사람들은 버전 번호를 포기하고 "Feisty fig"(또는 이와 유사한 것), "hardy heron", "europa" 및 "ganymede"와 같은 어리석은 이름을 사용하고 있습니다.물론 이것은 프로그램 변경을 중단하기 전에 목성의 달이 부족해지고 명확한 순서가 없기 때문에 어느 것이 더 새로운 것인지 알 수 없기 때문에 훨씬 덜 유용합니다.

포인트가 많을수록 릴리스가 더 마이너해집니다.그 이상의 실제적인 견고한 표준은 없습니다. 프로젝트 유지관리자가 결정한 내용에 따라 다른 의미를 가질 수 있습니다.

예를 들어 WordPress는 다음과 같은 내용을 따릅니다.

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은 일반적으로 새로운 기능인 중요한 릴리스가 될 것입니다.

숫자는 원하는 모든 것을 의미할 수 있지만 일반적으로 개별 구성 요소와 관련이 있는 것이 아니라 주요 구성 요소와 주요 구성 요소와 관련이 있습니다.마이너 대릴리스의 유지 관리 변경 사항.

다음 리소스를 확인하세요.
http://www.netbeans.org/community/guidelines/process.html
http://en.wikipedia.org/wiki/Release_engineering
http://www.freebsd.org/releases/6.0R/schedule.html

건배

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

상황에 따라 다르지만 일반적인 표현은 다음과 같습니다. 메이저.마이너.릴리스.빌드.

어디:

주요한 소프트웨어의 주요 릴리스 버전입니다. .NET 3.x를 생각해 보세요.
미성년자 소프트웨어의 부 릴리스 버전입니다. .NET x.5를 생각해 보세요.
풀어 주다 해당 버전의 릴리스입니다. 일반적으로 버그 수정으로 인해 이 버전이 증가합니다.
짓다 수행한 빌드 수를 나타내는 숫자입니다.

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

에서도 좋은 정보를 얻으실 수 있습니다. 주제에 관한 Wikipedia 기사.

메이저.마이너.버그

(또는 그에 대한 변형)

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

사소한 변경은 새로운 기능을 추가하지만 프로그램을 크게 변경하지는 않습니다.

주요(Major)은 오래된 기능을 손상시키거나 사용자가 프로그램을 사용하는 방법을 어떻게든 바꿀 정도로 큰 프로그램 변경입니다.

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이 내 추측일 것입니다.
그러나 제품마다 크게 다를 수 있습니다.

Major.minor.point.build는 일반적으로 사용됩니다.메이저와 마이너는 설명이 필요 없으며 포인트는 몇 가지 사소한 버그 수정에 대한 릴리스이며 빌드는 빌드 식별자일 뿐입니다.

일반적으로 다음과 같습니다.

MajorVersion.MinorVersion.Revision.Build

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

부 릴리스에도 기능이 추가되지만, 크기가 더 작고 때로는 베타 주요 릴리스에서 제거된 포팅 버전입니다.

세 번째 버전 번호 구성 요소가 있는 경우 일반적으로 중요한 버그 수정 및 보안 수정을 위한 것입니다.그 밖에도 제품에 따라 달라지는 부분이 너무 많아 일반적인 답변을 드리기는 어렵습니다.

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

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

"2"는 시리즈 내의 릴리스를 나타냅니다.종종 우리는 마지막 주요 릴리스에 포함되지 않은 기능을 파악하기 위해 이 위치를 사용합니다.이 위치(2)는 거의 항상 버그 수정과 함께 기능 추가를 나타냅니다.

대부분의 상점에서 "3"은 패치 릴리스/버그 수정을 나타냅니다.적어도 상업적인 측면에서는 이것이 중요한 기능 추가를 의미하는 경우는 거의 없습니다.기능이 위치 3에 나타나면 아마도 버그 수정 릴리스를 수행해야 한다는 사실을 알기 전에 누군가가 무언가를 체크인했기 때문일 것입니다.

"3" 위치 너머에 있습니까?사람들이 왜 그런 일을 하는지 전혀 모르겠고, 오히려 더 혼란스러워질 뿐입니다.

특히 일부 OSS는 이 모든 것을 제대로 처리하지 못합니다.예를 들어 Trac 버전 10은 실제로 0.10.X.X입니다.내 생각에 OSS 세계의 많은 사람들은 자신감이 부족하거나 주요 릴리스가 완료되었음을 알리고 싶어하지 않는 것 같습니다.

메이저 릴리즈.마이너 릴리즈.버그 수정의 패러다임은 꽤 일반적이라고 생각합니다.

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

사람들은 2.1, 2.0.1, 2.10과 같은 버전 번호 사이의 미묘한 차이를 항상 인식하지 못합니다. 기술 지원 담당자에게 이 문제로 인해 몇 번이나 어려움을 겪었는지 물어보세요.개발자는 세부 사항을 지향하고 계층 구조에 익숙하므로 이것이 우리의 사각지대입니다.

가능하다면 고객에게 더 간단한 버전 번호를 공개하세요.

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

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

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

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

나는 근거에 대해 더 많이 썼다. 여기.

버전 v1.9.0.1:이는 명시적인 버전 관리 체계입니다. 시험판 또는 -alpha,-beta와 같은 빌드에 이름을 사용하고 싶지 않을 때 사용됩니다.

1: 이전 버전과의 호환성이 손상될 수 있는 주요 버전

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

0:몇 가지 사소한 버그 수정

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

하지만 요즘에는 이러한 버전 관리 체계를 찾을 수 없습니다. Semantic Versioning [semver2.0]을 참조하세요.https://semver.org/

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

처음 두 개는 메이저와 마이너입니다. 나머지는 프로젝트, 회사, 때로는 커뮤니티에 따라 달라집니다.FreeBSD와 같은 OS에서는 보안 패치를 나타내는 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"인 반면, Delphi에서는 "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가 포함될 수 있습니다.

버전 번호를 생성할 때 다음과 같이 사용하십시오.

첫 번째 숫자는 주요 릴리스입니다.사용자 인터페이스를 크게 변경하거나 기존 인터페이스를 중단해야 하는 경우(사용자가 인터페이스 코드를 변경해야 함) 새 기본 버전으로 이동해야 합니다.
두 번째 숫자는 새로운 기능이 추가되었거나 내부적으로 뭔가 다르게 작동함을 나타냅니다.(예를 들어 Oracle 데이터베이스는 데이터 검색을 위해 다른 전략을 사용하기로 결정하여 대부분의 작업을 더 빠르게 하고 일부 작업을 느리게 만들 수 있습니다.) 기존 인터페이스는 계속 작동해야 하며 사용자 인터페이스는 인식 가능해야 합니다.
버전 번호 지정은 소프트웨어를 작성하는 사람에게 달려 있습니다. Oracle은 5개(!) 그룹을 사용합니다.Oracle 버전은 10.1.3.0.5와 같습니다.세 번째 그룹부터는 버그 수정이나 사소한 기능 변경만 적용해야 합니다.

소프트웨어 빌드 프로세스에 대한 참고 사항

덜 다양한 것은 major.minor의 처음 두 개일 것입니다. 그 다음은 빌드, 개정, 릴리스에서 사용자 정의 알고리즘(일부 MS 제품과 같은)에 이르기까지 무엇이든 될 수 있습니다.

모든 조직/그룹에는 고유한 표준이 있습니다.중요한 것은 어떤 표기법을 선택하든 고수해야 한다는 것입니다. 그렇지 않으면 고객이 혼란스러워질 것입니다.나는 일반적으로 3개의 숫자를 사용했다고 말했습니다.

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

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

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

모든 숫자에는 명확하고 중요한 기능이 있기 때문에 이 시스템은 우리에게 큰 도움이 됩니다.나는 다른 팀이 메이저 번호/마이너 번호 질문(얼마나 큰 변화가 메이저인지)을 놓고 씨름하는 것을 보았지만 그에 따른 이점은 없습니다.데이터베이스 개정을 추적할 필요가 없다면 3자리 또는 2자리 버전 번호로 이동하여 작업을 더 쉽게 만드세요!

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow