메이저 / 마이너 / 패치 버전 번호는 언제 변경합니까?

가능한 중복 :
어떤 "버전 명명 규칙"을 사용하십니까?

출시 직전 또는 직후에 주 / 부 / 패치 버전 번호를 변경합니까?

예 : 방금 전 세계에 1.0.0을 출시했습니다 (huzzah!). 하지만 너무 축하하지 마십시오. 6 주 안에 1.1.0이 나옵니다! 따라서 버그를 수정하고 새 빌드를 수행하십시오. 그 빌드는 무엇입니까? 1.1.0.0 또는 1.0.0.xxxy (여기서 xxxy는 1.0.0의 빌드 번호입니다)?

1.1.0에 들어가는 100 개의 기능과 버그가있을 수 있습니다. 따라서 1.1.0에 가깝지 않기 때문에 1.0.0.xxxy라고 부르는 것이 좋습니다. 그러나 다른 개발자는 2.0.0에서 작업 중일 수 있습니다.이 경우 빌드의 이름이 각각 1.0.0.xxxy 및 1.0.0.xxxz 대신 1.1.0.0 및 그의 2.0.0.0으로 더 잘 지정 될 수 있습니다.

소프트웨어를 출시 한 후에는 버전 번호가 즉시 증가해야합니다.

왜?

Semantic Versioning 과 같은 체계를 따르고 있으며 버전 에 빌드 번호 가 있다고 가정 해 봅시다 . [Major]. [Minor]. [Patch]. [Build]가있을 수 있습니다. 버전을 [Major]. [Minor]. [Patch] 부분으로 부르겠습니다.

개발 중에 여러 빌드를 작성하게됩니다. 각 빌드는 다음 릴리스의 개발 스냅 샷입니다. 개발 및 릴리스 빌드에 동일한 버전을 사용하는 것이 좋습니다. 버전은 당신이 작업하는 것을 풀어냅니다 으로 .

릴리스를 준비 중이고 소프트웨어가 모든 테스트를 통과 한 경우 버전을 업데이트해야했기 때문에 소프트웨어를 다시 빌드하고 다시 테스트하고 싶지 않습니다. 결국 릴리스를하면 "빌드 1.1.0.23"을 "버전 1.1.0"이라고합니다.

릴리스 후 증가 모델도 분기에 적합합니다. 기본 개발 지점이 있고 릴리스에 대한 유지 보수 지점을 작성한다고 가정하십시오. 릴리스 브랜치를 생성하는 순간 개발 브랜치는 더 이상 해당 릴리스의 버전 번호에 연결되지 않습니다. 개발 분기에는 다음 릴리스의 일부인 코드가 포함되므로 버전에 해당 코드가 반영되어야합니다.

일반적으로 내부 버전 번호로 SemVer 를 사용하려고 합니다. 버전 번호의 의미를 기반으로 한 릴리스에 대해 알 수있는 것이 좋습니다.

개발 중에는 가능한 경우 버전 번호를 즉시 변경하려고합니다 . 때로는 변경 사항이 주요 변경 사항인지 여부를 알기가 어렵 기 때문에 (내 버전 번호에 영향을 줄 수 있음) "돌에 설정되지 않은"항목이 없습니다.

구체적인 예를 설명하려면 :

• 개발 중에 시험판 버전은 1.0.1-alpha.1, 1.0.1-alpha.2 등이 될 것입니다.
• 버그 수정의 최종 릴리스는 버전 1.0.1입니다.

'공개 대상'제품 버전 번호는 종종 마케팅에 의해 설정되며 완전히 다릅니다. 이것은 내가 통제 할 수 없으므로 걱정할 필요가 없습니다.

답변에서 ABCD를 가정 해 봅시다. 각 구성 요소를 언제 늘립니까?

기본적으로 회사 정책에 따라 결정됩니다. 회사 정책은 다음과 같습니다.

• A-기능 또는 인터페이스의 현저한 변경 (> 25 %).
• B-기능 또는 인터페이스의 작은 변경 또는 추가
• C-인터페이스를 손상시키는 사소한 변경.
• D-인터페이스를 변경하지 않는 빌드 수정.

대규모 프로젝트 / 조직에서 주 버전과 부 버전 번호는 마케팅 부서에서 제어하며 일반적으로 마케팅 이유로 증가합니다. 조직에서 그룹은 매년 하나의 메이저 릴리스와 마이너 릴리스를 릴리스하는 것을 목표로합니다. 주요 릴리스에는 새로운 기능이 포함되어 있고 동일한 주요 버전 번호를 가진 모든 릴리스에 대해 API간에 이진 호환성이있을 것으로 예상됩니다. 그러나 마케팅은 약속 된 기능이 제공되지 않거나 개구리 경쟁을 뛰어 넘는 것처럼 보임에 따라 주요 버전 변경 사항을 마이너 버전으로 다운 그레이드하도록 선택할 수 있습니다.

메이저 및 마이너 빌드 번호 (abcd의 c 및 d)는 일반적으로 개발에 의해 제어됩니다. c는 빌드 번호이고 d는 특정 릴리스 또는 c 버전의 패치에 사용됩니다.

귀하의 경우 주 버전과 부 버전 번호를 변경하면 주 버전과 부 버전 번호가 정확한지 확인하는 것보다 관련성이 적습니다. 우리 조직에서는 소스 제어에서 분기 프로세스의 일부로 메이저 및 마이너 빌드 번호를 변경합니다. 기본 지점에는 일반적으로 최신 버전이 포함되어 있지만 마케팅에서 릴리스의 버전 번호를 아직 결정하지 않았을 수 있습니다.

우리는 이클립스 예제를 시도하고 따릅니다 . 내가 할 수있는 것보다 설명하는 것이 더 좋지만 실제로는 다음과 같이 작동합니다.

1.0.0.0을 릴리스 할 때 변경하는 버전 번호는 변경 유형에 따라 다릅니다.

• API에 영향을 미치지 않는 릴리스는 현재 API를 예상 한 방식으로 작동하게하는 뒤의 버그 수정을 고려하여 1.0.1에 릴리스됩니다.
• API에 추가되었지만 기존 API를 변경하지 않는 릴리스 인 경우 현재 클라이언트를 새 버전과 비교할 수없는 새 기능을 추가했을 수 있습니다. 여기에는 여러 가지 수정 사항이 포함될 수 있습니다.
• 릴리스는 현재 API를 중단하고 무언가를 제거하며 현재 클라이언트와 비교할 수없는 방식으로 무언가를 변경합니다. 이것은 위의 수정 중 임의의 수를 가질 수 있습니다.

버전 번호에서 4 번째 섹션을 사용하는 방법에 대해서는 Nuget (.net에 사용하는 패키지 관리 솔루션)의 여러 빌드를 구별하기 위해이 섹션을 사용합니다. 따라서 릴리스되지 않은 소프트웨어를 업데이트해야 할 때마다 캐시를 ​​지우지 않아도됩니다.

다음 빌드는 없습니다. 그 지점에서.

우리 계획의 이상적인 버전.

모든 지점의 버전 식별은 PRETTY_BRANCH_NAME- 빌드이며 PRETTY_BRANCH_NAME은 지점 생성시 고정됩니다.

분기 방식 (*)은 다음과 같습니다.

최상위 레벨 브랜치 인 PRETTY_BRANCH_NAME은 각각 코드 이름이며, 해당 레벨의 버전 번호는 의미가 없으며 계획된 계획이있을 수 있지만 릴리스 전에 변경 될 수 있습니다.

• 장기 개발이 이루어지는 TNG ( 차세대 ) 지점. 종종 우리는 그것을 가지고 있지 않으며 하위 브랜치를 결코 (릴리스)하지 않습니다.

• 현재 개발 중인 TCG ( 현재 세대 ) 지점 PRETTY_BRANCH_NAME은 코드 이름입니다.

• TPG ( 이전 세대 ) 브랜치 종종 더 이상 개발이 이루어지지 않지만 하위 브랜치에는 활동이있을 수 있습니다.

서브 브랜치는 주요 릴리스 시작에 대한 베타 인 경우 최상위 레벨 브랜치 (TCG의 느린 마이그레이션이있는 경우)로 구성됩니다. PRETTY_BRANCH_NAME은 "1.3.X"와 같습니다 (X는 숫자가 아니라 문자입니다. 여기에서 1.3 릴리스를 제공 할 것임을 의미합니다). 베타의 피드백은 여기에서 고려됩니다. 다음 주요 릴리스에 대한 작업은 TCG 지점.

이상적으로 릴리스는 해당 지점에서 스냅 샷이되어야하지만 완벽하지는 않으며 다른 사람들이 다음 마이너 릴리스를 계속 진행할 수 있도록 마지막 순간 변경을 수행해야한다는 것을 알고 있습니다. 따라서 하위 버전은 "1.3.X"지점에서 "1.3", "1.3.1"과 같이 예쁜 버전이 공식 버전 번호 (당시에는 마케팅조차도 변경하고 싶지 않음) 인 최종 안정화를 위해 만들어집니다. 각각의 마지막 빌드는 릴리스입니다.

우리가 네 번째 레벨을 가지고 있다면 하위 하위 브랜치 이름은 "1.3.0.X"였으며 그 중 하위 ^ 3 브랜치 "1.3.0.0" "1.3.0.1"이있었습니다.

(*) 릴리스 레벨에서. 이들 각각에 프로젝트 하위 브랜치가있을 수 있습니다.

소프트웨어를 판매하는 경우 판매 / 마케팅에서 더 큰 보너스를 얻을 때마다 새로운 주요 릴리스가 제공됩니다.

제어권이 있다면 :

1. 다음과 같은 경우 주요 릴리스 :

   • 이전 릴리스와는 파이썬 2에서 파이썬 3으로 변환하는 등의 비 호환성이 있습니다.

   • 새로운 기능이 많이 있습니다.

2. 기능의 작은 변화에 대한 부 릴리스.

3. 버그 수정을위한 패치 릴리스.