버전 번호는 어떻게합니까?

우리 회사는 제품을 만들고 있습니다. SVN에서 버전을 지정할 예정입니다. 그것은 웹 응용 프로그램이므로 기본적으로 일부 기능이없는 버전이 없으므로 항상 베타로 표시 될 수 있습니다. 그러나 그것이 기업 제품이 될 것이기 때문에 나는 "불안정한 감시"를 원하지 않습니다. 어떻게 버전 관리를 하시겠습니까? 1.0은 안정적입니까? 빌드 날짜가 버전 번호 여야합니까? 너희들이 어떻게 생각하는지 말해줘!

[ 메이저 ]. [ 마이너 ]. [ 릴리스 ]. [ 빌드 ]

전공 : 정말 마케팅 결정. 버전 1.0을 호출 할 준비가 되셨습니까? 회사는 고객이 더 많은 비용을 지불해야하는 주요 버전으로 간주합니까, 아니면 무료 일 수있는 현재 주요 버전의 업데이트입니까? R & D 결정이 적고 제품 결정이 더 많습니다.

minor : 메이저 가 증가 할 때마다 0에서 시작합니다 . 공개되는 모든 버전에 +1

출시 : 개발 마일스톤을 달성하고 내부적으로 (예 : QA로) 제품을 출시 할 때마다이를 늘리십시오. 이는 조직의 팀 간 커뮤니케이션에 특히 중요합니다. 말할 필요도없이, 동일한 '릴리스'를 두 번 (내부에서도) 해제하지 마십시오. minor ++ 또는 major ++에서는 0으로 재설정하십시오.

빌드 : SVN 개정이 될 수 있습니다.

내 현재 크롬 예 : 83.0.4103.61

xyzg

g 단위의 증분이 불안정합니다. z의 (또는 RC) 증분은 안정적이며 버그 수정을 의미합니다.
y 단위의 증가는 안정적이며 새로운 기능을 의미합니다.
x 단위의 증가는 100 % 이전 버전과의 호환성없이 안정적이며 주요 릴리스입니다.

한 번은 대규모 프로젝트를위한 정교한 "버전 관리 스타일 가이드"를 작성했습니다. 프로젝트를 구체화하지 못했지만 스타일 가이드는 여전히 온라인에서 사용할 수 있습니다 . 그것은 내 개인적인 의견 일 것입니다. 아마도 그것은 당신에게 도움이되거나 영감을 줄 것입니다.

긴 텍스트이므로 구성 요소 버전 관리 대 제품 버전 관리와 같은 것들에주의하십시오. 또한 OSS 커뮤니티에서 널리 사용되는 일부 버전 관리 체계에 대한 강력한 의견을 표명하지만이를 가지고 있습니다. ;-)

예를 들어 Subversion 개정 번호 사용에 동의하지 않습니다. TRUNK에서 개발을 계속하면서 릴리즈 된 버전을 유지하고 싶을 수 있으므로 유지 보수 브랜치를 설정하면 개정 번호 버전이 줄어 듭니다.

편집 : 요약하면 버전 관리 소스 파일, 구성 요소 및 전체 제품을 구분합니다. 구성 요소와 제품에 대해 별도의 xy versoning 시스템을 사용하며 둘 사이의 상호 의존성이 뛰어나 어떤 구성 요소 버전이 어떤 제품 버전에 속하는지 추적합니다. 또한 시스템을 중단하지 않고 알파 / 베타 / 릴리스 / 패치주기를 처리하는 방법에 대해서도 설명합니다. 실제로, 그것은 전체 개발주기에 대한 modus 피연산자이므로 체리 픽을 원할 수도 있습니다. ;-)

편집 2 : 충분한 사람들이 내 기사를 "좋은 답변"으로 만드는 데 도움이됨에 따라 기사를 다시 작성하기 시작했습니다. PDF 및 LaTeX 버전을 사용할 수 있으며, 더 나은 언어 및 설명 그래픽을 포함한 완전한 재 작성은 시간을 찾 자마자 따라 올 것입니다. 투표 해 주셔서 감사합니다!

Wikipedia에서 영감을 얻으십시오 : "소프트웨어 버전 관리"

또 다른 "신규"및 "상대적으로 인기있는"옵션은 시맨틱 버전 관리입니다.

요약:

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

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

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

abcd

단위 :
- D : 버그 수정
- C : 유지 보수, 예를 들어, 성능 향상
- B : 새로운 기능
- : 아키텍처 변화

필수 사항은 가장 왼쪽입니다. 예를 들어 새로운 기능과 버그가 수정 된 경우 b 만 늘리면 됩니다.

복잡한 엔터프라이즈 플랫폼 수준 종속성 관리 및 릴리스 버전 관리에 대한 경험을 바탕으로 Semi-Semantic Versioning 이라고하는 접근 방식을 추천합니다 .

기본적으로 Semantic Versioning 2.0을 기반으로 하지만 엄격하지는 않습니다.

반 의미 버전 세그먼트 :

<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]

기본 릴리스 세그먼트 형식 :

마케팅, 메이저, 마이너 패치

각 세그먼트는 영숫자를 허용해야하지만 논리적 증분 변경에는 순수한 숫자가 권장됩니다.

SemVer와 마찬가지로 역 호환성 계층을 나타 내기 위해 Major, Minor 및 Patch 구성 요소 를 권장하지만 Marketing 구성 요소 앞에 추가하는 것이 좋습니다 . 이를 통해 제품 소유자, 기능 epics / 그룹 및 비즈니스 문제가 기술 호환성 문제와 무관하게 주요 구성 요소에 부딪 칠 수 있습니다.

다른 답변과 달리 기본 세그먼트에 빌드 번호를 추가하지 않는 것이 좋습니다. 대신 '+'뒤에 출시 후 세그먼트를 추가하십시오 (예 : 1.1.0.0 + build.42). SemVer는이 빌드 메타 데이터를 호출하지만 Post-Release Segment가 더 명확하다고 생각합니다. 이 세그먼트는 기본 릴리스 세그먼트 의 호환성 정보와 관련이없는 것으로 접미사 데이터를 선언하는 데 유용합니다.. 그런 다음 지속적인 통합 빌드에 각 1 차 릴리스 후에 재설정되는 증분 빌드 번호가 추가 된 이전 릴리스 번호를 부여 할 수 있습니다 (예 : 1.1.0.0-> 1.1.0.0 + build.1-> 1.1.0.0 + build.2-> 1.1.0.1). 일부 사람들은 코드 저장소에 쉽게 연결할 수 있도록 svn 개정 번호를 여기에 넣거나 git commit sha를 선호합니다. 또 다른 옵션은 핫픽스 및 패치에 릴리스 후 세그먼트를 사용하는 것입니다. 새 릴리스 구성 요소를 추가하는 것이 좋습니다. 버전이 효과적으로 왼쪽 정렬 및 정렬되므로 패치 구성 요소가 증가하면 항상 제거 될 수 있습니다.

릴리스와 릴리스 후 세그먼트뿐만 아니라, 사람들은 종종 사용할 시험판 세그먼트를 알파, 베타 및 릴리스 후보와 같은 거의 안정 사전 릴리스를 나타냅니다. 이것에 대한 SemVer 접근 방식은 잘 작동하지만 영숫자 분류기 (예 : 1.2.0.0 + alpha.2 또는 1.2.0.0 + RC.2)에서 숫자 구성 요소를 분리하는 것이 좋습니다. 일반적으로 릴리스 후 세그먼트를 추가하는 것과 동시에 릴리스 세그먼트를 충돌 한 다음 다음에 주 릴리스 세그먼트를 충돌 할 때 시험판 세그먼트를 삭제합니다 (예 : 1.0.1.2-> 1.2.0.0-RC.1- > 1.2.0.0). 시험판 세그먼트가 추가되어 릴리스 버전이 출시됨을 나타내며, 일반적으로 더 많은 커밋에 따라 분 단위로 변경되지 않는보다 심도있는 테스트 및 공유를위한 고정 된 기능 세트 만 나타납니다.

거의 모든 유스 케이스를 다루는 방식 으로이 모든 의미를 의미 적으로 정의하는 것의 장점은 표준 방식으로 구문 분석, 정렬, 비교 및 ​​증가 할 수 있다는 것입니다. 이는 각각 독립적 인 버전이있는 여러 구성 요소 (마이크로 서비스 등)가 자체적으로 관리되는 종속성이있는 복잡한 응용 프로그램에 CI 시스템을 사용할 때 특히 중요합니다.

당신이 관심이 있다면, 나는 루비로 세미 시맨틱 파서를 썼다 . 이 패턴 만 사용하는 것이 아니라 그 패턴을 사용한 다른 앱을 관리 할 수 ​​있어야했습니다.

"버전 번호"는 내부 버전 관리 시스템의 문제입니다. 릴리스 번호는 다른 문제이며 KEPT와 달라야합니다.

MAJOR가 호환성 수준 (버전 2.x가 버전 1.x와 호환되지 않거나 적어도 버전 1.x와 크게 다름) 인 간단한 MAJOR.MINOR 릴리스 시스템 (v1.27과 같은)을 고수하고 MINOR는 버그 수정 릴리스 또는 사소한 개선 사항입니다. . XY 형식을 따르는 한 YEAR.MONTH (2009.12) 또는 YEAR.RELEASE (2009.3)와 같은 다른 시스템을 사용할 수도 있습니다. 그러나 실제로 정당한 이유가 없다면 MAJOR.MINOR을 고수하는 것이 가장 좋습니다.

XY 형식에 맞지 않는 것을 사용하지 마십시오. 배포판, 발표 웹 사이트 등이 귀하와 함께 작동하기 어려워지고 단독으로 프로젝트의 인기에 심각한 영향을 줄 수 있습니다.

(바람직하게 분산 된) 버전 관리 시스템에서 분기 및 태그를 사용하여 MAJORS 및 MINORS와 관련된 특정 내부 버전 번호를 각각 표시하십시오.

그리고 1.0은 안정적이어야합니다. 알파, 베타 또는 RC로 표시되지 않는 한 모든 릴리스는 안정적이어야합니다. 잘 알려지지 않은 불완전한 알파를 사용하십시오. 알려진 깨진 베타. "시도해보세요. 아마도 우리가 놓친 것들을 발견 할 것입니다." 이들 중 하나가없는 것은 (이상적으로는 물론) 테스트되고, 잘 알려져 있으며, 최신 매뉴얼이 있어야합니다.

요즘 Subversion 개정 번호를 사용하는 것이 매우 유명합니다.

SVN에 있다면 SVN 개정 번호를 사용하지 않는 이유는 무엇입니까?

이 웹 페이지의 오른쪽 아래를 보면 SVN 개정 번호 인 Stack Overflow 버전 번호가 표시됩니다.

버전 관리는 귀하에게 달려 있습니다. 필자가 생각한 첫 번째 버전에 1.0을 넣었습니다. 일부 소프트웨어 공급 업체는 1.0에 나쁜 평판을 줬기 때문에 다른 버전과 함께 빨리 따라 가고 싶을 수도 있습니다.

사용 된 정확한 빌드에 버전 번호를 연결하는 방법을 원하지만 최종 사용자에게 좋을 수도 있고 단순 할 수도 있습니다. 표준 버전 번호를 사용하고 포함 된 버전 번호로 SVN 저장소에 태그를 지정하십시오.

Subversion 개정 번호를 사용하는 것은 훌륭하고 간단하지만 버전 번호에서 정보를 제거합니다. 사용자는 이것을 나쁜 것으로 간주 할 수 있습니다.

귀하의 웹 응용 프로그램에는 일종의 배포 절차가 있으므로 Subversion의 각 개정판이 실제로 게시되지는 않습니다. "외부"(사용자 관점에서)가 언제 릴리스되고 있는지, 그리고 얼마나 많은 수정이 있을지 결정하는 것은 불가능하기 때문에 숫자는 거의 임의적입니다. 그것들은 증가 할 것이고, 나는 두 개정을 비교하는 것으로부터 어떤 종류의 거리 를 추측 할 수 있지만 그렇게 많지 는 않을 것이라고 생각합니다 .

클래식 버전 번호는 릴리스를 "극화"하는 경향이 있으므로 사용자는 어떤 종류의 기대치를 만들 수 있습니다. "저는 1.0 버전을 사용하고 있습니다. 이제 버전 1.1에이 기능이 추가되었습니다. 그 말이 흥미로워 요."

물론,이 드라마는 제품의 실제 차이에 의해 유발 된 것보다 더 흥미로운 버전 번호를 선택하는 회사들과 함께 팽창 될 수도 있습니다.

버전 체계 : [major]. [minor]. [devrel] [mark]
[major] : 개발에 급격한 변화가있을 경우 증가합니다.
[minor] : 개발에 약간의 변화가있는 경우 증가합니다.
[devrel] : 버그 수정이 있으면 증가합니다. major ++ 또는 minor ++ 인 경우 0으로 재설정하십시오.
[mark] : a, b 또는 rc : a는 알파 릴리스, b는 베타 릴리스, rc는 릴리스 후보입니다. 1.3.57a 또는 1.3.57b 또는 1.3.57rc와 같은 버전은 1.3.57 이전 버전입니다. 0.0.0에서 시작하십시오.

우리는 메이저 버전을 증가시킬 때를 결정하는 데 너무 많은 시간을 보냈습니다. 일부 상점에서는 거의 사용하지 않으므로 1.25.3과 같은 릴리스를 사용하고 다른 상점에서는 릴리스를 위해 15.0을 제공합니다.

나는 그 사실에 매료되어 모든 사람에게 주요 릴리스 번호는 단지 1 년이고 마이너는 일년 내내 순차적 릴리스라고 확신했습니다. 사용자는 그것을 좋아하는 것처럼 보였고 다음 버전 번호를 생각해내는 것은 쉬운 일이 아닙니다.

Year.Release.build

• 연도 = 현재 연도
• release = 새로운 기능을 갖춘 공개 릴리스 순서 #-매년 1로 재설정
• 빌드 = 버그 수정 및 내부 릴리스에 대해 증가

편집하다

** 이제 지속적으로 개선 된 내부 앱을위한 것입니다 **

마케팅 및 재무 목적으로 연중 서로 다른 시간에 주요 릴리스를 갖는 것이 중요한 상용 앱에서는 작동하지 않을 수 있습니다.

이 질문이 존재하는 이유는 구성 관리를 수행하는 데 합의 된 단일 방법이 없기 때문입니다.

버전 번호를 좋아하는 방법은 정수를 1에서 증가시키는 것입니다. 설명하거나 문서화해야 할 다중 부품 버전 번호를 원하지 않습니다. 그리고 SVN rev 번호를 사용하고 싶지 않습니다. 설명도 필요합니다.

이를 위해서는 SVN 위에 일부 릴리스 스크립트가 필요합니다.

나는 그 지역에 대한 경험이 거의 없다. 그러나 여기에 내가 할 일이 있습니다.

1. 개정 번호 매기기 계획을 선택하고 고수하십시오. 일관성을 유지하십시오.
2. 각 버전 변경 사항은 크게 변경되어야합니다 . 변경이 얼마나 작고 버전 번호에 반영된 변경 수준은 사용자에게 달려 있습니다.

물론 많은 다른 사람들이 제안한 것처럼 svn 개정 번호를 사용할 수 있습니다!

이게 도움이 되길 바란다.

간단한 major.minor.julian_date 구문을 사용합니다.

어디;

• major-첫 번째 릴리스는 1입니다. 주요 새로운 기능이나 변경 사항이 도입되면 이전 버전과 호환되지 않으므로이 수가 증가합니다.
• 부-주요 이정표 릴리스. 생산에 의해 추진되는 각 빌드에 대해이 수가 증가합니다.
• julian_date- 빌드가 QA로 푸시 된 Julian Day .

1/15에서 QA로 푸시 된 첫 번째 릴리스의 예는-> 1.0.015입니다.
입니다. 3/4에서 프로덕션으로 푸시 된 첫 번째 릴리스의 예는-> 1.1.063입니다.

완벽하지는 않지만 빌드를 매일 QA에 푸시 할 때 편리합니다.

여기 좋은 정보가 있습니다 :

파일 / 어셈블리 버전을 변경하는시기

우선, 파일 버전과 어셈블리 버전이 서로 일치 할 필요는 없습니다. 빌드마다 파일 버전을 변경하는 것이 좋습니다. 그러나 동일한 파일의 두 버전 간 차이점을 알 수 있도록 각 빌드마다 어셈블리 버전을 변경하지 마십시오. 그 파일 버전을 사용하십시오. 어셈블리 버전을 언제 변경할지 결정하려면 고려해야 할 빌드 유형 (배송 및 비 배송)에 대해 논의해야합니다.

배송하지 않는 빌드 일반적으로 배송하지 않는 어셈블리 버전은 배송 빌드간에 동일하게 유지하는 것이 좋습니다. 이는 버전 불일치로 인한 강력한 이름의 어셈블리 로딩 문제를 방지합니다. 일부 사람들은 게시자 정책을 사용하여 각 빌드에 대한 새 어셈블리 버전을 리디렉션하는 것을 선호합니다. 그러나 배송 이외의 빌드에는 권장하지 않습니다. 모든로드 문제를 피할 수는 없습니다. 예를 들어 파트너가 앱을 x 복사하면 게시자 정책을 설치하지 못할 수도 있습니다. 그러면 컴퓨터에서 제대로 작동하더라도 앱이 앱을 손상시킵니다.

그러나 동일한 컴퓨터의 다른 응용 프로그램이 다른 버전의 어셈블리에 바인딩 해야하는 경우 LoadFrom / etc를 사용하지 않고도 각 앱마다 올바른 버전을 사용할 수 있도록 빌드마다 다른 어셈블리 버전을 제공하는 것이 좋습니다.

운송 빌드 운송 빌드의 해당 버전을 변경하는 것이 좋은지 여부는 최종 사용자에게 바인딩이 작동하는 방식에 따라 다릅니다. 이 빌드들이 나란히 또는 제자리에 있기를 원하십니까? 두 빌드 사이에 많은 변화가 있습니까? 그들은 일부 고객을 깰 것인가? 그것이 깨지는 것을 걱정합니까 (또는 사용자가 중요한 업데이트를 사용하도록 강요하고 싶습니까)? 그렇다면 어셈블리 버전을 늘리는 것을 고려해야합니다. 그러나이 작업을 너무 많이 수행하면 오래된 디스크로 인해 사용자 디스크가 흩어질 수 있습니다.

어셈블리 버전을 변경할 때 하드 코드 된 버전을 새 버전으로 변경하려면 헤더 파일에서 변수를 버전으로 설정하고 소스의 하드 코딩을 변수로 바꾸는 것이 좋습니다. 그런 다음 빌드 중에 프리 프로세서를 실행하여 올바른 버전을 넣으십시오. 변경 사항으로 인해 버그를 잡을 수있는 시간이 충분하도록 배송 직전에 버전을 변경하는 것이 좋습니다.

또는 '생각한'버전 번호 쉼표 하위 버전 번호를 사용하십시오. zB :

1.0.101 // 개정 101, 릴리스

또는 1.0.101-090303 // 릴리스 날짜와 함께 사용합니다.