MAJOR.MINOR.BUILDNUMBER.REVISION

그 형식으로 작성된 것을 본 적이 없습니다. 제가 일하는 곳에서는 MAJOR.MINOR.REVISION.BUILDNUMBER 양식을 사용합니다. 여기서 :

• MAJOR은 주요 릴리스입니다 (일반적으로 많은 새로운 기능이나 UI 또는 기본 OS)
• MINOR은 이전 주 릴리스의 부 릴리스 (아마도 일부 새로운 기능)입니다.
• REVISION은 일반적으로 이전 부 릴리스 (새 기능 없음)에 대한 수정입니다.

li>

• BUILDNUMBER는 개정판의 최신 빌드마다 증가합니다.

예를 들어 개정판이 QA (품질 관리)에 릴리스 될 수 있으며 다음과 같은 문제가 발생합니다. 변경이 필요합니다. 버그가 수정되고 동일한 REVISION 번호로 QA에 다시 릴리스되지만 BUILDNUMBER가 증가합니다.

댓글

• +1 : That ‘는 다른 곳에서도 ‘ 본 것과 거의 같습니다. 저는 ‘ 일부 회사에서 BUILDNUMBER에 DateTime 스탬프를 사용하는 방식을보고 좋아했습니다.
• +1 : ” MAJOR.MINOR.REVISION.BUILDNUMBER ” 형식은 이해하기 쉽고 의미가 있습니다. MSDN 사이트 (문제에서 업데이트 된 링크)에서 BUILDNUMBER.REVISION 양식을 보았고 완전히 혼란 스러웠습니다.
• 이상합니다. 가장 의미있는 수정이 마지막 일 것으로 예상합니다. ‘ 가장 많이 변경되는 숫자입니다.
• @Izkata, 실제로 빌드 우리가 의료 기기를 만들고 있기 때문에 엄격한 버전 관리를 사용하는 지금 당장 주 계약에서 사용하는 방식만큼 번호가 가장 많이 바뀝니다. 업데이트 된 개정판은 QA (Quality Assurance)에서 테스트해야하는 이전 소프트웨어에 대한 수정 사항이 있음을 나타냅니다. 이것은 3 일 동안 광범위한 테스트를 수행하는 완전히 분리 된 부서입니다 (FDA 지침에 따라). 문제가 발견되면 새 빌드 (재 컴파일 및 링크)와 재 테스트를 요구하는 추가 코드 변경이 필요할 수 있지만 개정 번호는 동일하게 유지됩니다.
• @tcrosley 나는 그것을 추측한다 ‘ 용어가 명확하지 않은 경우입니다. 버전 관리의 수정을 생각하고있었습니다.

전체적인 혼란은 다른 의미 체계 . 용어는 단지 다른 의미 일뿐입니다.

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

하지만 REVISION을 늘리면 새로운 영구 릴리스 브랜치를 나타내므로 BUILD 앞에 배치합니다.이 접근 방식의 단점은 다음과 같은 이벤트 시퀀스를 얻을 수 있다는 것입니다.

• 커밋 번호 4711 : Alice가 기능 A를 추가했습니다.
• CI가 빌드 1.2.3.100을 생성합니다. li>
• 커밋 번호 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 : Alice가 기능 A를 수정했습니다. 1.2.100 브랜치
• CI가 빌드 1.2.100.1을 생성합니다.

REVISION이라는 용어는

• 제품 개정 (대부분의 사람들이 사용하는 방식)
• 특정 매일 빌드 (MS가 수행하는 작업입니다.)

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

이 경우 CI 도구는 저장소 태그를 생성하므로 필요할 때 언제든지 사용할 수있는 필요한 정보를 얻을 수 있습니다. SVN을 사용하면 태그와 분기가 똑같은 방식으로 구현되기 때문에 훨씬 간단 해집니다. 태그는 /tags 아래에있는 분기에 불과합니다.

참조 또한

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

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

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

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

또 다른 유용한 정보는 TFS 분기 가이드

댓글

• 이것은 훌륭한 대답입니다! +1

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

major.minor [.build [.revision]]

구성 요소는 다음과 같이 관례 적으로 사용됩니다. 다음과 같습니다.

주요 : 이름은 같지만 주 버전이 다른 어셈블리는 서로 바꿔서 사용할 수 없습니다. 더 높은 버전 번호는 이전 버전과의 호환성을 가정 할 수없는 제품의 주요 재 작성을 나타낼 수 있습니다.

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

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

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

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

댓글

• 아무도이 표준을 모르는 이유가 당황 스럽습니다. 여기에있는 모든 답변은 빌드가 끝났지 만 빌드되지 않는다고 주장합니다. ‘ 수정이 매우 간단하다는 것을 이해하지 못합니다. 핫픽스를 의미합니다. 빌드를 릴리스 한 다음 추가 빌드를 생성하지만, 해당 릴리스로 돌아가서 수정해야하는 경우 릴리스 된 특정 빌드가 새 릴리스에 대해 변경되었음을 표시하도록 개정을 업데이트합니다.
• +1 for 정당한 빌드 번호가있는 답변입니다. 수정본이 동일하게 유지되는 경우 단순히 숫자를 늘리는 것은 다소 쓸모가 없습니다 (시간에 의존하는 미친 빌드 시스템이없는 경우). 빌드 번호를 사용하여 어떤 컴파일러, 플랫폼 등이 유용한 지 알립니다.
• Build를 는 놓친 중요한 포인트 인 것 같습니다. ‘ 코드 변경 (‘ 완전히 새로운 Major / Minor 증가가 필요하지 않음) 인 경우 Revision도 변경해야합니다.
• @PeterX 재 타겟팅시 빌드 별 변경의 경우처럼?
• ” 빌드 번호의 차이는 동일한 소스의 재 컴파일을 나타냅니다. ” 문서와 모순되는 것 같습니다. 수정 한 후에는 더 이상 동일한 소스가 아닙니다. REVISION 전에 BUILD를 사용하는 것은 개정이 ” 프로세서, 플랫폼 또는 컴파일러 변경 “을 나타내는 빌드와 관련된 경우에만 의미가 있습니다. 그래서 나는 이러한 설명을 사용할 때 대부분이 REVISION 범프로 보는 것이 실제로 사소한 범프 여야한다고 생각합니다. 문서에서는 핫픽스에 REVISION을 사용한다고 언급했지만 Id는 핫픽스가 모든 빌드에 적용될 것이라고 가정하므로 사소한 문제가되어야합니다. 논리적 일관성을 원합니다 !!

적어도 몇 가지 다른 작업이 가능합니다. 다음을 참조하는 빌드 번호를 상상해보십시오.

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

2. 연속 통합 서버 식별자.이 경우 CI 서버는 실행되는 각 빌드에 번호를 지정할 수 있습니다. 따라서 빌드 번호는 성공적인 빌드가되는 것이고 수정 부분은 “이 시나리오에서 필요하지 않습니다.

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

댓글

• +1 for # 1. 저는 소스 제어 버전 #, 소스 제어에서 해당 버전에 대해보고 된 버그를 훨씬 쉽게 찾을 수 있기 때문입니다.
• @MasonWheeler : SVN을 사용하는 경우 훌륭하게 작동합니다.하지만 dcvs에 도달하면 다람쥐를 얻다 와이. 이것이 제가 svn에 대해 가장 그리워하는 부분 중 하나입니다. ‘ 추가하겠습니다.

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

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

대부분의 지속적 통합 엔진은 자동 생성 된 고유 빌드 번호를 허용합니다.

수정 버전은 다음의 패치에 사용할 수 있습니다. 빌드합니다. 두 팀이 한 제품에 대해 작업한다고 가정 해 보겠습니다.

팀 1은 주요 개발 팀이며 다음 버전 스키마 1.0.X.0으로 야간 빌드를 생성합니다. 여기서 X는 증가합니다. 이제 그들은 1.0.50.0 빌드에 있습니다. 팀 2는 때때로 빌드를 수행하고 있습니다. 지난주 빌드 인 1.0.43.0을 가져와 사용하기 시작한다고 가정 해 보겠습니다. 팀 1은 1.0.43.0에서 문제를 발견하면 팀 1이 1.0.51.0으로 진행됩니다.

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

희망 이것은 명확하고 유용합니다.

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

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

ProgramName version major.minor.build.revision

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

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

build : 게시 된 major.minor 버전에서 매우 작은 변경 사항을 표시하는 데 사용합니다. 이것은 레이아웃, 색 구성표 등의 변경 일 수 있습니다.

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

따라서 이러한 방식으로 완료되거나 중단 된 프로젝트는 다음 릴리스가 나올 때까지 수정하고 사용할 수 있습니다.

이를 통해 이러한 유형의 버전 관리가 작동하는 방식을 더 잘 이해할 수 있기를 바랍니다. 나에게는 이러한 유형의 버전 관리를 사용할 때 모든 유형의 실질적인 의미를 갖는 유일한 정의와 관행입니다.

릴리스 ID의 마지막 번호로 빌드 번호 만 본 적이 있습니다. 빌드 번호에 대한 개정판을 어떻게 만들 었는지 잘 모르겠습니다. 빌드되지 않은 리소스 중 일부를 변경 한 경우 ( 아이콘, DB 스크립트 등) 일 수도 있지만 최근에 작업 한 대부분의 프로젝트에는 버전 제어가 모두 포함되어 있으므로 설치 / 릴리스를 만들 때 빌드 프로세스에서 선택합니다. @David가 설명하는 것과는 다르지만 타임 스탬프가있는 빌드 번호를 좋아합니다 (나는 major.minor.revision.HHMM을 좋아합니다). 하지만 제가 일하는 곳에서는 빌드 서버가 생성하는 순차 번호 만 사용합니다.

원하는대로입니다. 될 것입니다. 내 major.minor.build.revision에 대해 year.month.day.hhmm을 사용하는 경향이 있습니다. 내가 분당 1 개 이상을 생산한다면 뭔가 잘못된 것입니다. 간단한 증분을 사용하거나 정교한 생성기를 본 적이 있습니다. 당신 이 원하는 것은 무엇입니까? 그들이해야 할 일은 당신이 익숙한 소스에 도달하도록 만드는 것입니다. 그 결과물을 만들 수 있습니다.

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

jkohlhepp과 마찬가지로 버전의 세 번째 부분을 사용하여 SubVersion에 개정 번호를 표시하고 네 번째 부분을 사용하여 지속적인 통합 서버 (Jenkins for us)의 빌드 번호입니다. 이렇게하면 몇 가지 이점이 있습니다. CI 서버에서 설정 한 버전 번호를 사용하면 실수로 발생할 수있는 수동 단계가 제거됩니다. 놓친; 개발자가 개발 PC에서 건방진 릴리스를 수행하지 않았는지 쉽게 확인할 수 있습니다 (이 경우이 숫자는 0이됩니다). 그리고 그것은 우리가 때때로 매우 유용하다고 생각하는 버전 번호를 보는 것만으로도 소프트웨어의 일부를 및 빌드 한 CI 작업에서 생성 된 코드에 다시 연결할 수있게 해줍니다.

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

1.01.2.1234

빌드 번호는 2.1234이지만 2 부분은 자주 변경되지 않으므로 대부분의 사람들은 1234를 사용합니다.

코멘트

• OP는 개정 ID의 빌드 번호가 아니라 빌드 번호가 무엇인지 묻습니다.