MAJOR.MINOR.BUILDNUMBER.REVISION의 빌드 번호는 정확히 무엇입니까

빌드 번호에 대해 생각하는 것은 새로운 야간 빌드가 작성 될 때마다 새 BUILDNUMBER가 생성되어 해당 빌드에 지정된다는 것입니다. 내 7.0 버전 응용 프로그램의 야간 빌드는 7.0.1, 7.0.2 등입니다. 그렇습니까? 그렇다면 빌드 번호 뒤에 REVISION을 어떻게 사용합니까? 또는 매일 밤마다 빌드 후에 REVISION 부분이 증가합니까? 우리는 각 야간 빌드를 참조 않습니다 ... 여기에 조금 혼란 스러워요 BUILD ?

형식은 다음과 같습니다. AssemblyVersion-MSDN

나는 그 형태로 쓰여진 것을 본 적이 없다. 내가 일하는 곳에서는 MAJOR.MINOR.REVISION.BUILDNUMBER 형식을 사용하고 있습니다. 여기서 MAJOR는 주요 릴리스 (보통 많은 새로운 기능 또는 UI 또는 기본 OS에 대한 변경)이며 MINOR는 부 릴리스 (아마도 새로운 기능)입니다. 이전 주요 릴리스 인 REVISION은 일반적으로 이전 부 릴리스 (새로운 기능 없음)에 대한 수정이며 BUILDNUMBER는 최신 개정 빌드마다 증가합니다.

예를 들어, 개정이 QA (품질 관리)로 릴리스 될 수 있으며 변경이 필요한 문제가 다시 발생합니다. 버그는 수정되어 동일한 수정 번호를 사용하지만 BUILDNUMBER가 증가한 QA로 다시 릴리스됩니다.

전체 혼란은 MS가 "빌드 번호", 특히 "개정"에 사용 하는 서로 다른 의미론 에서 비롯됩니다 . 용어는 단지 다른 것을 의미합니다.

대부분의 사람들 (자체 포함) 은 어떤 이유로 든 새 빌드를 만들어야 할 때마다 더 높은 빌드 번호를 얻는 의미 버전 번호 체계 를 사용합니다. 우리에게는 핫픽스가 또 다른 코드 변경으로 간주되며 CI 부분이 실행될 때마다 BUILD 부분이 자동으로 증가합니다. MAJ.MIN.REV가 동일한 모듈은 상호 교환 가능한 것으로 간주되며 BUILD는 가장 최근의 모듈을 알려줍니다.

그러나 개정 개정은 새로운 영구 릴리스 브랜치를 나타내므로 BUILD 앞에 배치해야합니다. 이러한 접근 방식의 단점은 다음과 같은 일련의 이벤트를 얻을 수 있다는 것입니다.

• 커밋 번호 4711 : Alice가 기능 A를 추가 함
• CI는 빌드 1.2.3.100을 생성합니다
• 커밋 번호 4712 : Bob이 피처 B를 수정했습니다.
• 커밋 번호 4713 : Alice 고정 기능 A ( "핫픽스")
• CI는 빌드 1.2.3.101을 생성합니다

보시다시피, 핫픽스는 다음 빌드에 포함 된 유일한 변경 사항이 아니며 Bob의 수정도 해당 빌드의 일부가됩니다. 현재 브랜치를 안정화하려면 Bob이 버그를 추가했는지 여부를 확신 할 수 없으므로 문제가 발생할 수 있습니다.

MS는 두 용어를 다르게 사용합니다. BUILD 번호는 자동으로 증가하지 않으며, 특정 버전의 코드에 사용되는 코드를 고정하기 위해 일종의 릴리스 브랜치로 간주 될 수 있습니다. REVISION은 해당 BUILD 브랜치에 적용된 추가 "핫"변경을 나타냅니다. 따라서 순서는 다음과 같습니다.

• 커밋 번호 4711 : Alice가 기능 A를 트렁크 / 마스터에 추가
• Carl은 빌드 브랜치를 만듭니다. 1.2.100
• CI는 빌드 1.2.100.0을 생성합니다
• 커밋 번호 4712 : 트렁크 / 마스터의 Bob 수정 기능 B
• 커밋 번호 4713 : 1.2.100지점의 Alice 고정 기능 A
• CI는 빌드 1.2.100.1을 생성합니다

REVISION이라는 용어는

• 제품 개정 (그건 대부분의 사람들이 그것을 사용하는 방법)
• 특정 일일 빌드 개정 (MS 가하는 일)

두 프로세스의 주요 차이점은 CI 빌드에 핫픽스를 적용 할 수 있는지 여부와 프로세스의 어느 시점에서 분기가 만들어 지는지 여부입니다. 모든 테스트에 성공한 후 언제든지 특정 빌드를 선택하고 해당 버전을 제품의 다음 공식 릴리스로 승격시키려는 경우이 측면이 중요합니다.

이 경우 CI 도구는 리포지토리 태그를 생성하므로 필요한 정보를 항상 사용할 수 있습니다. SVN을 사용하면 태그와 분기가 동일한 방식으로 정확하게 구현되므로 태그가 더 단순 해집니다. 태그는에 위치한 분기에 지나지 않습니다 /tags.

또한보십시오

TFS 분기 전략 의 FAQ 섹션에서 :

P1 (핫픽스) 티켓을 어떤 지점에서 수정해야합니까?

• P1은 프로덕션에서 실행되는 코드베이스에 가장 가까운 지점에 고정되어야합니다. 이 경우 P1은 Prod 분기에 고정되어야합니다. 다른 지점에 수정 사항을 적용하고 프로덕션 변경 사항을 적용하면 후속 반복에서 반제품 또는 테스트되지 않은 코드가 릴리스 될 위험이 있습니다.

• 이제 Prod 브랜치에 대해 직접 작업하는 것이 안전한지 논쟁 할 수 있습니다. 즉각주의를 기울여야하는 P1은 시스템의 근본적인 문제가되어서는 안됩니다. 근본적인 문제인 경우 고객과의 추가 분석 및 논의가 필요할 수 있으므로 제품 백 로그에 추가해야합니다.

또 다른 좋은 읽을 거리는 TFS 분기 안내서입니다

Microsoft는 해당 Version클래스 의 MSDN 설명서에서 .NET 버전 번호의 각 구성 요소의 목적을 설명합니다 . 관련 부분은 다음과 같습니다.

major.minor [.build [.revision]]

구성 요소는 다음과 같이 규칙에 따라 사용됩니다.

주 : 이름은 같지만 주 버전이 다른 어셈블리는 서로 호환되지 않습니다. 버전 번호가 높을수록 이전 버전과의 호환성을 가정 할 수없는 제품을 크게 다시 작성했을 수 있습니다.

부 : 두 어셈블리의 이름과 주 버전 번호는 동일하지만 부 버전 번호가 다른 경우 이전 버전과의 호환성을 위해 상당한 향상을 나타냅니다. 이 높은 부 버전 번호는 제품의 포인트 릴리스 또는 이전 버전과 호환되는 새 버전의 제품을 나타낼 수 있습니다.

빌드 : 빌드 번호의 차이는 동일한 소스의 재 컴파일을 나타냅니다. 프로세서, 플랫폼 또는 컴파일러가 변경 될 때 다른 빌드 번호가 사용될 수 있습니다.

개정판 : 이름, 주 버전 및 부 버전 번호는 동일하지만 개정판이 다른 어셈블리는 완전히 상호 교환 할 수 있습니다. 이전에 릴리스 된 어셈블리의 보안 허점을 수정하는 빌드에서 더 높은 개정 번호가 사용될 수 있습니다.

http://msdn.microsoft.com/en-us/library/system.version.aspx

빌드 번호 참조를 상상할 수있는 최소한 두 가지가 있습니다.

1. 릴리스 된 소스 제어 버전. 예를 들어, 개정판 # 12345가 릴리스 된 경우, 빌드 번호를 지정하여 추적 할 수 있으며 패치가 적용되면 주 또는 부 버전을 증가시키는 새로운 기능이 아니기 때문에 개정이 올라갈 수 있습니다. 누군가 빌드를 다시 실행하려는 경우 빌드 번호를 기억해야합니다.

2. 지속적인 통합 서버 식별자. 이 경우 CI 서버는 실행하는 각 빌드에 번호를 매길 수 있으므로 빌드 번호는 성공적인 빌드를 얻는 것이므로이 시나리오에서는 개정 부분이 필요하지 않습니다.

내가 모르는 다른 것들이있을 수 있지만 이것들은 코드베이스의 숫자와 관련하여 내가 아는 큰 것입니다.

빌드 번호는 일반적으로 모든 빌드마다 증가하므로 고유합니다.

간단히하기 위해 일부는 MAJOR 또는 MINOR 번호가 충돌 할 때마다 빌드 번호를 재설정합니다.

대부분의 Continuous Integration 엔진은 자동 생성 고유 빌드 번호를 허용합니다.

개정판은 빌드 패치에 사용할 수 있습니다. 두 팀이 한 제품에서 일한다고 가정 해 봅시다.

팀 1은 주요 개발 팀이며 X가 증가하는 다음 버전 스키마 1.0.X.0으로 야간 빌드를 생성합니다. 현재 팀은 빌드 1.0.50.0입니다. 팀 2는 때때로 빌드를 수행합니다. 지난주부터 1.0.43.0의 빌드를 가져 와서 사용한다고 가정 해 봅시다. 팀 2가 1.0.43.0에서 문제를 발견하면 팀 1은 1.0.51.0으로 진행합니다.

이제 팀 1은 해당 빌드 (43)를 가져 와서 문제를 해결하고 팀 2에 빌드 1.0.43.1을 제공합니다. 수정 사항은 기본 빌드에서도 전파 될 수 있으므로 변경 사항은 1.0.52.0에 나타납니다.

이것이 명확하고 도움이되기를 바랍니다.

* 개정은 프로젝트에 관련된 모든 사람이 동일한 빌드를 사용하지 않고 특정 빌드를 패치해야 할 때 유용합니다.

내가 어떻게보고 사용하는지 말씀 드리겠습니다 ....

ProgramName 버전 major.minor.build.revision

전공 : 저에게는 현재 진행중인 프로젝트가 있습니다. 동일한 프로그램 이름의 새 프로젝트를 시작할 때까지 번호가 변경되지 않습니다. 이것은 문자 그대로 동일한 성별의 새 프로그램을 작성한다는 것을 의미합니다 (예 : access v1-access v-2-access v-3 * 모두 동일한 프로그램이지만 완전히 다시 작성 됨).

부 : 이것은 현재 게시 된 프로젝트에 기능을 추가하고 있음을 의미합니다. 예를 들어 영수증을 인쇄하거나 사진을 가져 오는 기능을 추가했을 수 있습니다. 기본적으로 추가 기능 지금 추가하고 다음 주요 릴리스가 완료되기를 기다리지 않습니다.

빌드 : 게시 된 major.minor 버전에서 매우 작은 변경 사항을 나타내는 데 사용합니다. 레이아웃, 색 구성표 등이 변경 될 수 있습니다.

개정 : 현재 게시 된 major.minor.build에서 버그 수정을 나타내는 데 사용합니다. 현재 프로젝트를 진행하지 않고 버그가 발생하는 경우가 있습니다. 이 버그는 수정하여 게시해야합니다. 그것은 이미 제대로 작동하도록 이미 게시 한 내용을 수정하고 있음을 의미합니다. 새로운 빌드, 새로운 추가 작업 또는 새로운 주요 버전을 시작하는 경우에도 이것을 사용합니다. 다음 메이저, 마이너 또는 빌드 릴리스를 기다리는 동안 게시 된 버전을 반드시 패치해야합니다.

따라서 이러한 방식으로 완성되거나 중단 된 프로젝트는 여전히 수정되어 다음 릴리스가 게시 될 때까지 사용할 수 있습니다.

이것이이 유형의 버전 관리가 어떻게 작동해야하는지 더 잘 이해할 수 있기를 바랍니다. 나 에게이 유형의 버전 관리를 사용할 때 모든 유형의 진정한 의미를 갖는 것은 유일한 정의와 연습입니다.

릴리스 ID의 마지막 번호로 빌드 번호 만 본 적이 있습니다. 빌드 번호 수정 방법을 잘 모르겠습니다. 아마도 빌드되지 않은 리소스 (아이콘, DB 스크립트 등) 중 일부를 변경했다고 가정하지만 최근에 작업 한 대부분의 프로젝트는 버전 제어하에있는 모든 것들을 가지고 있으므로 빌드 프로세스는 언제 그들을 선택합니다. 인스톨러 / 릴리스 만들기. @David가 설명하지는 않지만 타임 스탬프가 찍힌 빌드 번호를 좋아합니다 (major.minor.revision.HHMM을 좋아합니다). 그러나 내가 일하는 곳에서는 빌드 서버가 생성하는 일련 번호를 사용합니다.

jkohlhepp과 마찬가지로 버전의 세 번째 부분은 SubVersion에 개정 번호를 표시하고 네 번째는 지속적인 통합 서버 (Jenkins for us)의 빌드 번호를 표시합니다. CI 서버에서 설정 한 버전 번호를 사용하면 실수로 놓칠 수있는 수동 단계가 제거됩니다. 개발자가 개발 PC에서 건방진 릴리스를 수행하지 않았는지 쉽게 확인할 수 있습니다 (이 숫자는 0 임). 버전 번호를 확인하여 소프트웨어를 생성 한 코드 와 CI 작업 에 소프트웨어를 연결할 수 있습니다.

그것은 당신이 원하는 것입니다. 나는 나의 주요한 마이너 빌드 리비전에 year.month.day.hhmm을 사용하는 경향이있다. 분당 1 개 이상을 생산하는 경우 문제가 있습니다. 간단한 증분을 사용하거나 정교한 생성기를 보았습니다. 무엇 을 원 하십니까 ? 그들이해야 할 일은 출력을 만드는 데 사용되는 소스에 도달하도록 만드는 것입니다.

마지막 두 자리는 총 빌드 번호입니다

1.01.2.1234

빌드 번호는 2.1234이지만 대부분의 사람들은 2 부분이 자주 바뀌지 않기 때문에 1234 만 사용합니다.

우리 팀은 세 번째 숫자 (개정)를 Subversion 저장소의 개정 번호로 사용합니다. 우리는 실제로 빌드를 생성하는 TeamCity Continuous Integration Server의 빌드 번호로 네 번째 숫자 (빌드)를 사용합니다. TeamCity는 빌드 프로세스 중에 올바른 #가 포함 된 새 AssemblyInfo 파일을 작성합니다.