응용 프로그램 버전 관리 전략

TFS / VSTS를 사용한 ALM
TFS / VSTS를 사용한 Application Lifecycle Management에 대한 블로그
글로벌 버전 관리 전략 & # 8211; AssemblyInformationalVersion.
AssemblyInfo 파일의 세 번째 (선택적) 버전 지정 특성 인 AssemblyInformationalVersion에 대해 들어 본 적이 있습니다. 아니? 읽어주세요!
체계적인 (어셈블리) 버전 번호 매기기 전략이 없으면 어떤 버전에 어떤 변경 내용이 포함되었는지 확인하는 기능이 손실됩니다. 필자는 항상 어떤 소스 파일이 어떤 빌드에 들어 갔는지와 특정 환경에 현재 배포 된 소프트웨어 버전을 정확하게 알아야합니다. 랜덤 버전 번호 매기기 시스템은 혼란을 야기하며 조만간 배포 위험을 초래할 것입니다. 프로덕션에서 버그를 재생하기 위해 정확한 소스 파일을 가져 오는 것은 악몽이 될 것입니다.
공용 언어 런타임을 사용하는 어셈블리의 모든 버전은 어셈블리 수준에서 수행됩니다. 특정 버전의 어셈블리 및 종속 어셈블리 버전이 어셈블리 매니페스트에 기록됩니다. 런타임의 기본 버전 정책은 구성 파일의 명시 적 버전 정책에 의해 무시되지 않는 한 응용 프로그램을 빌드하고 테스트 한 버전으로 만 실행한다는 것입니다.
각 프로젝트에는 AssemblyVersion 특성과 AssemblyFileVersion 특성을 포함하는 AssemblyInfo 파일이 있습니다.
AssemblyVersion : 빌드 및 런타임에 어셈블리를 찾고 연결하고로드하기 위해 프레임 워크에서 사용하는 버전 번호입니다. 프로젝트의 어셈블리에 대한 참조를 추가하면이 버전 번호가 포함됩니다. 런타임에 CLR은로드 할이 버전 번호가있는 어셈블리를 찾습니다. 그러나이 버전은 어셈블리의 강력한 이름이 서명 된 경우에만 이름, 공개 키 토큰 및 문화 정보와 함께 사용됩니다. 어셈블리의 서명이 strong-named 인 경우 파일 이름 만로드에 사용됩니다. AssemblyFileVersion : 파일 시스템에서와 같이 파일에 주어진 버전 번호입니다. Windows 탐색기에 표시됩니다. 참조를 위해 프레임 워크 또는 런타임에서 사용되지 않습니다.
그러나 AssemblyVersion과 AssemblyFileVersion의 차이점은 무엇입니까? 여러 번, 동일한 버전이 두 속성에 모두 적용된 것을 볼 수 있습니다. & # 8230; 그러나 프레임 워크가 제공하는이 두 가지 (다른) 속성은 왜 있습니까? AssemblyVersion은 전체 소프트웨어 응용 프로그램의 공용 버전이어야하며 AssemblyFileVersion은 전체 응용 프로그램의 일부일 수있는 특정 구성 요소의 버전입니다. AssemblyFileVersion은 소프트웨어 응용 프로그램의 개별 구성 요소를 패치하는 데 중요 할 수있는 추가 빌드 버전 정보를 저장하는 가장 좋은 장소입니다.
AssemblyVersion을 할당하고 증분하는 방법을 지정하려면 Semantic Versioning 권장 사항을 따르십시오. AssemblyFileVersion의 경우 특정 빌드 정보를 포함하는 경향이 있습니다. 종종 특정 SemVer 버전의 소프트웨어를 빌드 (및 테스트)해야합니다.
예를 들어, 소프트웨어 응용 프로그램의 릴리스 1은 AssemblyVersion을 1.0.0 (모든 구성 요소)으로 설정할 수 있지만 개별 구성 요소의 AssemblyFileVersion은 빌드 시스템의 고유 한 빌드 번호를 나타내는 1.0.15234.2로 설정할 수 있습니다. 특정 날짜와 개정판에 링크되어 있습니다 : & # 8220; 15 & # 8221; = 2015 년; & # 8220; 234 & # 8221; = 2015 년 일수; & # 8220; 2 & # 8221; = 두 번째 빌드가 해당 날짜에 처리되었습니다. 또한 나중에 유사한 AssemblyVersion (1.0.0)을 사용하지만 다른 AssemblyFileVersion (1.0.15235.1)을 사용하여 개별 구성 요소를 나중에 패치 할 수 있습니다.
그래서 이것을 Visual Studio의 테스트 프로젝트에 적용하고 프로젝트를 빌드 한 후 어셈블리 세부 정보를 봅니다. & # 8230;
이제 혼란스러워해야합니다! 제품 버전에 AssemblyFileVersion이 표시되고 AssemblyVersion이 어디에 있습니까? 여기서 문제는 새 Visual Studio 프로젝트에 전체 소프트웨어 응용 프로그램의 공용 버전을 나타내는 세 번째 버전 특성 인 AssemblyInformationalVersion이 포함되어 있지 않다는 것입니다. CLR은이 세 번째 (선택적) 버전 특성을 신경 쓰지 않습니다. 간단히 말해 AssemblyVersion에 대한 동일한 Semantic Versioning 규칙을 AssemblyInformationalVersion에 적용해야합니다.
아하! 이게 훨씬 나아 졌어? 이제 배치 된 어셈블리에서이 메타 데이터를 쉽게 추출 할 수 있으며이 정보는 소프트웨어의 about 상자에 잘 나열 될 수 있습니다. 이 접근법의 유일한 문제점은 AssemblyFileVersion에 & # 8221; 패치 & # 8221; AssemblyVersion의 숫자 (시맨틱 버전)이지만 AssemblyFileVersion이 고유하고 빌드 시스템에서 실행되는 고유 빌드에 링크 될 수 있다는 사실 때문에 무시할 수 있습니다. 이 작업 방식은 복잡한 소프트웨어 응용 프로그램에서 버전 관리가 제대로 적용될 수 있는지에 대한 개인적인 해석이며 Microsoft의 공식 지침을 반영하지 못합니다. 필자의 목표는 명확한 버전 관리 전략이없는 잠재적 인 위험을 소프트웨어 개발자가 인식하도록하는 것입니다.
이제 AssemblyInfo 파일에 수동으로 버전 정보를 설정하고 로컬 Visual Studio 빌드에서 소프트웨어를 릴리스하지 마십시오. 간소화 된 빌드 프로세스에서 고유 한 빌드 및 버전 번호 생성은 중앙에서 조정됩니다. 효율적인 문제 해결 및 추적 성을 위해 생성 된 어셈블리에는 시스템 빌드 번호로 쉽게 추적 할 수있는 고유 한 식별자가 찍혀 있어야합니다.
다음 글에서는 TFS 2015의 새로운 빌드 시스템으로이 글로벌 버전 전략을 어떻게 달성 할 수 있는지에 대해 이야기 할 것입니다.
소식 탐색.
회신을 남겨주 답장을 취소하십시오.
Real Semver는 & # 8220; 1.2.4-beta04 & # 8221;와 같은 시험판 태그를 허용합니다. Semver는 또한 빌드 번호, 날짜, 커밋 또는 변경 세트와 같은 메타 데이터를 '1.0.0 + 20130313144700'과 같이 허용합니다.
AssemblyInformationalVersion은 1.2.3.4와 같은 고전적인 버전 표기법 이외의 다른 것을 허용하는 유일한 필드입니다. AssemblyVersion 및 AssemblyFileVersion은 엄격한 버전 표기법 만 허용합니다. 그리고 모든 부분은 내가 믿는 65536 개로 제한됩니다 (왜 우리는 날짜에 이상한 표기법이 필요한가?).
AssemblyInformationalVersion과 AssemblyVersion을 동일한 버전으로 설정하는 것이 좋겠지 만이 강력한 기능 / 아이디어는 느슨해집니다. 그리고 나머지는 AssemblyFileVersion에 빌드 번호에 대한 날짜 표현을 넣는 것입니다 (1.2.3.4의 형식 인 한)
어쩌면 AssemblyInformationalVersion은 AssemblyVersion으로 시작해야하지만 태그와 메타 데이터를 추가 할 수 있습니까?
nupkg를 패키징 할 때 AssemblyInformationalVersion이 사용됩니다. 사전 출시 패키지를 만들 수 있기 때문에 어느 쪽이 좋을까요? 그러나 자동화 된 빌드에 대한 시험판 태그를 구성하는 것은 쉽지 않을 수 있습니다.
우리가 할 수있는 말은 혼란스럽고 혼란스럽고 프레임 워크가이 모든 것을 염두에두고 만들어지지 않았다는 것입니다. 상황을 악화시키기 위해, 우리는 이러한 쓸데없는 세부 사항을 파악하는 대신 실제 할 일을합니다 🙂
글로벌 어셈블리 정보는 좋은 아이디어입니다. 그런데 Assembly Versioner 및 Info Updater는 관리자 UI / 어셈블리 버전 및 모든 프로젝트 / 어셈블리에 대한 기타 정보를 단일 UI로 도울 수 있습니다.
Visual Smarter에는 위의 두 가지 기능보다 훨씬 많은 기능이 있습니다.
공통 어셈블리 버전 / 정보 파일을 공유하는 것은 모든 어셈블리 / 프로젝트가 동일한 정보 / 버전을 갖는 것으로 가정하면 좋은 생각입니다. 그렇지 않으면 Assembly Versioner 및 Info Updater가 마지막 순간에 구출 될 수 있습니다.
Visual Smarter에는 위의 두 가지 기능보다 훨씬 많은 기능이 있습니다.

파일 / 어셈블리 버전을 변경해야하는 경우.
먼저 파일 버전과 어셈블리 버전이 서로 일치 할 필요는 없습니다. 각 빌드마다 파일 버전이 변경되는 것이 좋습니다. 그러나 각 파일의 두 버전 간 차이점을 알 수 있도록 각 빌드에서 어셈블리 버전을 변경하지 마십시오. 그것을 위해 파일 버전을 사용하십시오. 어셈블리 버전을 변경할시기를 결정할 때는 고려해야 할 빌드 유형 (배송 및 비 배송)에 대한 논의가 필요합니다.
일반적으로, 선적 간 조립품 버전을 선적 빌드간에 동일하게 유지하는 것이 좋습니다. 이렇게하면 버전 불일치로 인해 엄격하게 명명 된 어셈블리로드 문제를 피할 수 있습니다. 일부 사용자는 게시자 정책을 사용하여 각 빌드에 대해 새 어셈블리 버전을 리디렉션하는 것을 선호합니다. 그러나 비 배송 구조의 경우이를 권장합니다. 모든로드 문제를 피할 수는 없습니다. 예를 들어 파트너가 앱을 x 복사하면 게시자 정책을 설치하지 못할 수 있습니다. 그런 다음 앱이 컴퓨터에서 정상적으로 작동하더라도 앱이 손상 될 수 있습니다.
그러나 동일한 컴퓨터의 여러 응용 프로그램이 서로 다른 버전의 어셈블리에 바인딩해야하는 경우가있을 경우 LoadFrom / etc를 사용하지 않고도 각 응용 프로그램에 맞는 올바른 응용 프로그램을 사용할 수 있도록 다른 어셈블리 버전을 빌드하는 것이 좋습니다.
배송 빌드를 위해 해당 버전을 변경하는 것이 좋은지 여부는 최종 사용자가 바인딩을 사용하는 방법에 따라 다릅니다. 이 빌드를 나란히 배치하거나 적절한 위치에 배치 하시겠습니까? 두 빌드간에 많은 변경 사항이 있습니까? 그들은 몇몇 고객을 깰 것인가? 당신이 그것을 깨뜨리는 것에 관심이 있습니까 (또는 사용자에게 중요한 업데이트를 사용하도록 강요하고 싶습니까)? 그렇다면 어셈블리 버전을 증가시키는 것을 고려해야합니다. 하지만 너무 많은 시간을 사용하면 오래된 어셈블리가있는 사용자의 디스크가 쌓일 수 있습니다.
어셈블리 버전을 변경하면.
하드 코딩 된 버전을 새로운 버전으로 변경하려면 헤더 파일의 버전으로 변수를 설정하고 소스의 하드 코딩을 변수로 바꾸는 것이 좋습니다. 그런 다음 올바른 버전으로 빌드하는 동안 프리 프로세서를 실행하십시오. 나는 직전에 제품을 출시 한 직후 버전을 변경하는 것을 권장합니다. 변경 사항으로 인해 버그를 잡을 시간이 더 많습니다.
버전 관리를 정의하는 한 가지 방법은 각 부분에 의미 론적 의미를 부여하는 것입니다.
새로운 relase로 호환성이 깨졌을 때 N. x에서 N + 1.0으로 이동 호환성을 손상시키지 않는 새로운 기능이 추가되면 N. M에서 N. M + 1로 이동 버그 수정이 추가되면 N. M.X에서 N. M.X + 1로 이동하십시오.
위의 내용은 단지 하나의 예일뿐입니다. 여러분에게 맞는 규칙을 정의하고 싶을 것입니다. 그러나 사용자가 버전을보고 비 호환성이 예상되는지 빠르게 알리는 것은 매우 좋습니다.
사람들이 무엇을 기대하는지 알 수 있도록 규칙을 게시하는 것을 잊지 마세요.
시맨틱 버전 관리는 이것을 적용하는 방법에 대한 일련의 지침과 규칙을 가지고 있습니다. 따라 가기 매우 간단하고 효과적입니다.
가장 먼저 어셈블리 버전과 파일 버전의 차이점을 익히는 것이 좋습니다. 불행하게도, AssemblyInfo 파일에 대해서는 AssemblyVersion 만 넣고 FileVersion은 같은 값을 기본값으로 사용한다는 점에서 이들을 동일하게 취급하는 경향이 있습니다.
이 어셈블리는 공유 어셈블리라고 했으므로 이진 수준에서 공유한다는 것을 의미합니다 (다양한 솔루션에 프로젝트를 포함하지 않음). 그렇다면 어셈블리 버전을 변경하는 것에 대해 신중히 생각하고 싶습니다. 어셈블리 버전을 GAC에 넣을 수 있도록 강력한 이름을 지정하는 데 사용되며 어셈블리 전체 이름도 구성합니다. 어셈블리 버전이 변경되면 app. config 파일에 어셈블리 리디렉션 항목을 추가하지 않고도 어셈블리 버전을 사용하는 응용 프로그램에 심각한 변경 사항이있을 수 있습니다.
명명에 관해서는 회사 이름 지정 규칙 (있는 경우)과 라이브러리의 목적에 달려 있다고 생각합니다. 예를 들어, 이 라이브러리가 특정 제품이나 비즈니스 라인에 특정한 것이 아닌 "핵심"(또는 시스템 레벨) 기능을 제공하면 다음과 같이 이름을 지정할 수 있습니다.
그것이 더 큰 도서관의 일부라면, 또는 간단히 말해서.
버전 번호를 늘릴 때까지는 여전히 주관적이며 빌드 번호의 각 부분을 나타내는 부분에 따라 다릅니다. 기본 Microsoft 구성표는 Major. Minor. Build. Revision입니다. 그렇다고해서 자신 만의 정의를 내놓을 수는 없습니다. 가장 중요한 것은 전략에 일관성을 유지하고 정의와 규칙이 모든 제품에서 의미가 있는지 확인하는 것입니다.
거의 모든 버전 구성에서 처음 두 부분은 Major. Minor입니다. 주 버전 번호는 대개 큰 변경 사항 및 / 또는 변경 사항이있을 때 증가하며, 부 버전 번호는 일반적으로 급격한 변경 사항이 아닌 변경 사항이 있음을 나타 내기 위해 증가합니다. 다른 두 숫자는 상당히 주관적이고 "빌드"(종종 날짜 값이 순차적으로 변경되거나 순차적으로 업데이트되는 숫자와 함께 변경되는 경우)와 "개정"또는 패치 번호 일 수 있습니다. 또한 빌드가 자동 빌드 시스템에서 순차적으로 증가하는 숫자 인 곳에서 (Major. Minor. Revision. Build에게) 되돌려 보았습니다.
어셈블리를 내보낼 때 어셈블리 주 버전과 부 버전이 형식 라이브러리 버전 번호로 사용됩니다.
마지막으로 자세한 정보를 보려면 다음 리소스 중 일부를 살펴보십시오.

애플리케이션 버전 전략
App Store를 통해 가져 오기 우리의 응용 프로그램 에서이 게시물을 읽으십시오!
애플리케이션 버전 관리 전략은 무엇입니까? [복제]
이 질문에는 이미 답변이 있습니다.
최고의 응용 프로그램 버전 전략에 대한 SO 커뮤니티의 의견을 얻는 데 관심이 있습니다.
애플리케이션의 버전 번호를 어떻게 추적합니까? 해당 버전의 각 숫자 / 문자의 의미에 대한 공식적인 정의가 있습니까?
앱의 버전이 다른 숫자 / 문자열은 앱의 의미가 무엇입니까?
앱에서 자동화 된 업데이트 시스템 (예 : Sparkle)을 사용하고 있으며 귀하의 행동 방식이 얼마나 좋았습니까?
베타 테스터 또는 앱의 시험판 테스터를위한 별도의 업데이트 절차가 있습니까?
gnat, MichaelT, Kilian Foth, GlenH7, Rein Henrichs Apr 29 '13 at 2:42에 의해 중복으로 표시됩니다.
이 질문은 전에 질문을 받았고 이미 답변이 있습니다. 이러한 답변으로 귀하의 질문에 완전히 답변하지 못하면 새로운 질문을하십시오.
stackoverflow에서 마이 그 레이션 5 월 18 일 13시 48 분.
이 질문은 전문적이고 열광적 인 프로그래머를위한 사이트에서 왔습니다.
애플리케이션의 버전 번호를 어떻게 추적합니까? 해당 버전의 각 숫자 / 문자의 의미에 대한 공식적인 정의가 있습니까?
앱의 버전이 다른 숫자 / 문자열은 앱의 의미가 무엇입니까?
나는 다음을 사용한다 :
Major - Major 버전은 제품의 확실한 릴리스입니다. 기능에 중대한 변화가있을 때 증가했습니다.
마이너 버전은 새 기능이나 주요 버그 수정이 추가 될 때마다 증가합니다.
업그레이드 / 패치 - 업그레이드는 제품을 최신 버전의 제품으로 대체하는 것을 의미합니다. 지정된 주요 릴리스에서 업그레이드가 제공되는 경우에만 증가됩니다. 패치 버전은 0으로 시작하고 버그가 해결 된 경우에만 증가합니다.
빌드 번호 - 새 빌드가 생성되면 빌드 번호가 증가합니다.
앱에서 자동화 된 업데이트 시스템 (예 : Sparkle)을 사용하고 있으며 귀하의 행동 방식이 얼마나 좋았습니까?
우리는 야간 빌드라고 부르는 야간에 앱을 자동으로 빌드하는 빌드 도구를 사용하며 빌드가 생성 될 때마다 빌드 번호가 증가합니다.
베타 테스터 또는 앱의 시험판 테스터를위한 별도의 업데이트 절차가 있습니까?
매일 아침 BAT (빌드 수락 테스트)를 호출하고 야간 빌드를 확인하는 야간 빌드에 대한 테스터 테스트.
먼저 "최고의"전략에 동의하지 않는 것 같습니다. 현재 프로젝트에서 내 경험 만 공유 할 수 있습니다.
시스템 버전은 빌드 특성에서 수동으로 정의됩니다. 팀이 새 릴리스에 동의하면 발생합니다. 추가적인 버전 관리로서 우리는 CI 빌드에 의해 자동으로 생성되는 빌드 번호를 사용합니다.
Ubuntu 명명 체계 YY. MM. version. patch_buildNumber를 대충 따릅니다. Major. Minor 버전 관리가 고객의 기대를 망쳐 놨음을 발견했습니다.)
관리자가 응용 프로그램을 롤아웃해야하기 때문에 자동 업데이트가 없습니다.
테스트 릴리스는 GA 출시보다 더 자주 발생하지만 모두 지원해야합니다.
나는 많은 버전 시스템을 테스트했고, 이제는이 버전에 꽤 만족한다.
Major는 수동으로 설정되고 주요 개선 사항을 포함하는 버전을 참조하십시오. Minor는 수동으로 설정되며 업그레이드 및 유지 관리 릴리스를 참조하십시오. 수정 사항 개정은 자동으로 생성되며 저장소의 정확한 개정을 참조합니다.
마지막 하나는 버전 관리에있어 매우 유연합니다. 여러 클라이언트에 여러 버전을 제공 할 수 있으며 디버그 및 디버깅이 가능합니다. repos에서 특정 버전을 가져 와서 쉽게 수정 한 다음 트렁크로 다시 병합하십시오.
빌드, 패키징 & amp; 게시는 완전히 자동화되어 있습니다. 유일한 수동 작업은 마지막 패키지를 FTP로 프로덕션 서버로 옮기는 경우입니다. 우리는 생산 현장에서 쓰레기를 전달하지 않도록 통제권을 유지하려고합니다. 얼리 어답터가 출시 노트를 읽고 버전을 다운로드하여 사용할 수있는 예비 단계로 이동합니다. 특정 버그에 직면 한 고객은이 버전 중 하나를 사용하여 고정 된 버전을 매우 빨리 얻을 수 있습니다.
오픈 소스 라이브러리를위한 시맨틱 버저 닝 (Semantic Versioning)을 사용하고 있으며 다른 라이브러리와도 작업하기가 훨씬 쉽다. 버전 변경이 의미하는 바를 이해할 수있는 공통 기반을 제공합니다. 도서관은 여전히 ​​베타 버전입니까? 버그 수정을위한 릴리즈인가요? API 변경 사항이 깨지십니까?
이것은 기본적으로 대부분의 오픈 소스 프로젝트에서 이미 사용 된 최상의 버전 관리 방식을 체계적으로 정리 한 것입니다.

애플리케이션 버전 전략
App Store를 통해 가져 오기 우리의 응용 프로그램 에서이 게시물을 읽으십시오!
모범 사례 : 소프트웨어 버전 관리 [닫힘]
여가 시간에 개발 한 소프트웨어를 재미있게 버전을 출시하는 방법에 대한 가이드 라인이나 표준 모범 사례가 있습니까? 그렇지만 일부 사람들은이 소프트웨어를 사용하게 될 것입니다. 버전 1에 대해 (예 : 버그 수정, 지원 등)에 대해 알 수 있도록 해당 소프트웨어의 버전을 변경해야한다고 생각합니다.
하지만 버전 관리는 어디에서 시작해야합니까? 0.0.0? 또는 0.0? 그리고 숫자를 늘리는 방법은? 주요한 방출. 마이너 변화? 버전 관리 시스템에 대한 커밋이 다른 버전이되어서는 안됩니까? 또는 생산적인 방식으로 사용되는 버전에만 해당 되는가?
bummi, animuson & # 9830;에 의해 주로 의견 기반으로 마감되었습니다. 8 월 2 일 13시 43 분.
많은 좋은 질문은 전문가의 경험을 토대로 어느 정도 의견을 제시하지만, 이 질문에 대한 답변은 사실, 참고 문헌 또는 특정 전문 지식보다는 의견에 거의 근거를 두는 경향이 있습니다. 이 질문을 도움말 센터의 규칙에 맞게 수정하려면 질문을 수정하십시오.
Flexo & # 9830; 3 월 21 일 21:32
이 질문은 역사적인 의미가 있기 때문에 존재하지만이 사이트에 대한 주제에 관한 좋은 질문으로 간주되지 않으므로 여기에서 비슷한 질문을 할 수있는 증거로 사용하지 마십시오. 이 질문과 답변은 고정되어 있으며 변경할 수 없습니다. 자세한 정보 : 도움말 센터.
12 답변.
"릴리스"첫 번째 버전이 어떤 식 으로든 불완전하다는 것을 안다면, 버전 1부터 시작해야합니다.
버전을 증가시키는 방법은 귀하의 선택에 달려 있지만 메이저, 마이너, 빌드 번호 매기기를 가이드로 사용하십시오.
소스 컨트롤에 커밋 할 모든 버전을 다른 버전으로 가질 필요는 없습니다. 곧 버전 번호가 곧 커질 것입니다. 새 버전을 외부 세계에 출시 할 때만 버전 번호를 증가시켜야합니다 (어떤 방식 으로든).
따라서 버전 1.0.0.0에서 버전 2.0.0.0으로 주요 변경 사항을 변경하면 (예 : WinForms에서 WPF로 변경) 더 작은 변경을하면 1.0.0.0에서 1.1.0.0으로 이동합니다 (png 파일에 대한 지원이 추가됨). 사소한 변경을하면 1.0.0.0에서 1.0.1.0로 변경하십시오 (버그 수정).
모든 체크 인 / 커밋에 대해 증가 할 빌드 번호로 최종 번호를 상세히 사용하고 싶다면 (하지만 너무 멀다고 생각합니다).
x. y.z 종류의 버전 관리를 사용합니다.
엑스 메이저 릴리스.
y - 부 릴리스.
z - 빌드 번호.
나는 기본적으로이 패턴을 따른다.
준비가되면 소스 레포에서 코드를 분기하고 0.1.0 태그를 지정하고 0.1.0 브랜치를 만들고 헤드 / 트렁크는 0.2.0 스냅 샷 또는 이와 비슷한 코드가됩니다.
나는 트렁크에만 새로운 기능을 추가하지만 지점에 대한 백 포트 수정은 0.1.1, 0.1.2,.
제품이 기능 완료로 간주되고 주요 단점이없는 경우 버전 1.0.0을 선언합니다.
그때부터 모든 사람이 메이저 버전을 늘릴시기를 결정할 수 있습니다.
내 응용 프로그램에이 규칙을 사용합니다.
. y = 기능 번호, 0-9. 변경 사항에 버그 수정이 있거나없는 새로운 기능이 포함 된 경우이 숫자를 늘리십시오. z = 핫픽스 번호, 0-
. 변경 사항에 버그 수정 만 포함 된 경우이 숫자를 늘리십시오.
새로운 응용 프로그램의 경우 버전 번호는 1.0.0으로 시작합니다. 새 버전에 버그 수정 만 포함 된 경우 버전 번호가 1.0.1이되도록 핫픽스 번호를 늘리십시오. 새 버전에 버그 수정이 있거나없는 새로운 기능이 포함 된 경우 기능 번호를 늘리고 핫픽스 번호를 0으로 재설정하여 버전 번호가 1.1.0이되도록하십시오. 기능 번호가 9에 도달하면 기본 버전 번호를 높이고 기능 및 핫픽스 번호를 0으로 재설정하십시오 (2.0.0 등)
우리는 어디에서 a. b.c. d를 사용합니다.
a - major (클라이언트에 대한 전달 증가) b - minor (클라이언트에 전달시 증가) c - 개정 (내부 릴리스에서 증가) d - build (순항 제어에 의해 증가)
A. B.C 접근 방식의 또 다른 예는 Eclipse 번들 버전 관리입니다. Eclipse 번들에는 네 번째 세그먼트가 있습니다.
이클립스에서 버전 번호는 4 개의 세그먼트로 구성된다 : 각각 3 개의 정수와 각각 major. minor. service. qualifier라는 문자열. 각 세그먼트는 다른 의도를 캡처합니다.
주요 세그먼트는 API에서 파손을 나타냅니다. 마이너 세그먼트는 "외부에서 볼 수있는"변경 사항을 나타냅니다. 서비스 세그먼트는 버그 수정과 수정 프로그램 세그먼트가 특정 빌드를 나타내는 개발 스트림 변경을 나타냅니다.
또한 날짜 버전 체계가 있습니다 (예 : YYYY. MM, YY. MM, YYYYMMDD).
첫 번째 모습은 출시일에 대한 인상을주기 때문에 매우 유익합니다. 그러나 나는 제품 수명주기에서 제품의 정확한 지점을 항상 알고 싶어하기 때문에 x. y.z 체계를 선호합니다 (Major. minor. release)
기본적인 대답은 "It depends"입니다.
버전 관리에 대한 귀하의 목표는 무엇입니까? 많은 사람들이 version. revision. build를 사용하며, dev. revision이 아니라 공개 버전이기 때문에 version. revision을 전 세계에 광고합니다. 체크인 '버전'을 사용하면 버전 번호가 커지게됩니다.
프로젝트를 계획하고 있다면 중요한 변경 사항, 버그 수정 또는 기능 / 기능이 포함 된 릴리스의 사소한 변경 및 증가 버전으로 릴리즈에 대한 개정을 증가시킵니다. 베타 또는 야간 빌드 유형 릴리스를 제공하는 경우 빌드를 포함하도록 버전을 확장하고 모든 릴리스에서 버전을 증가 시키십시오.
그래도 하루가 끝나면 그것은 당신에게 달려 있으며 당신에게 의미가 있어야합니다.
Mahesh가 말했듯이 : x. y.z 종류의 버전 관리를 사용합니다.
x - 메이저 릴리스 y - 마이너 릴리스 z - 빌드 번호.
당신은 아마 datetime을 추가하기를 원할 것입니다. 아마 z 대신에.
다른 릴리스가있을 때 마이너 릴리스를 증가시킵니다. 주요 릴리즈는 대개 0 또는 1로 유지되며, 실제로 변경 사항을 적용 할 때 변경됩니다 (소프트웨어가 이전 릴리스와 호환되지 않는 지점에 있거나 전체 프레임 워크를 변경 한 경우)
당신은 당신이 항상 다른 사람들이하고있는 것을 볼 수 있는지 확인할 수 있습니다. 오픈 소스 소프트웨어는 리포지토리에 대한 액세스를 허용하는 경향이 있습니다. 예를 들어 SVN 브라우저에서 svn. doctrine-project. org를 가리키고 실제 프로젝트에서 사용 된 버전 시스템을 살펴볼 수 있습니다.
버전 번호, 태그, 모든 것이 있습니다.
우리는 다음과 같은 a. b.c 접근법을 따른다 :
응용 프로그램에서 몇 가지 주요 변경 사항이있는 경우 '증가'를 선택하십시오. 우리는 1.1 응용 프로그램을 3.5로 업그레이드하는 것과 같습니다.
새로운 CR이나 향상과 같은 사소한 변경 사항이있는 경우에는 'b'증분이 구현됩니다.
코드에 몇 가지 결함 수정 사항이있는 경우 'increment'c '.
최저 (비 핫픽스) 세그먼트에서 버전 관리를 시작합니다. 이 세그먼트를 10으로 제한하지 않습니다. 빌드를 추적하지 않는 한 증분을 적용 할시기를 결정하면됩니다. 품질 보증 단계가있는 경우 품질 보증을 통과하고 출시 될 때 가장 낮은 세그먼트에 증분을 적용한 다음 다음 세그먼트를 적용 할 수 있습니다. 주요 동작 / UI 변경 사항의 최상단 세그먼트를 그대로 둡니다.
당신이 나를 좋아한다면, 당신은 소프트웨어의 진행 속도에 맞추기 위해 그것을 방법의 하이브리드로 만들 것입니다.
나는 가장 받아 들여지는 패턴이 a. b.c라고 생각한다. 특히 QA / 규정 준수가 혼합 된 경우에는. b.c. d입니다. 나는 주류를 위해 포기했던 버전의 정규적인 부분 인 데서 너무 많은 단서를 가지고있다.
빌드를 추적하지 않기 때문에 핫픽스가 포함되어 있지 않으면 a. b.c 패턴을 사용하고 싶습니다. 핫픽스를 적용해야 할 때 매개 변수 d를 날짜와 함께 적용합니다. 나는 시간 매개 변수를 d로 채택했습니다. 왜냐하면 일이 실제로 생산에서 날아갈 때 항상 잠재력이 있기 때문입니다. 생산 수정을 위해 분기 할 때만 d 세그먼트 (YYYYMMDDHHNN)를 적용합니다.
나는 개인적으로 va. b revc의 소프트웨어 계획에 반대하지 않을 것이다. 여기서 c는 YYYYMMDDHHMM 또는 YYYYMMDD이다.
그 모든 말. 구성하고 실행할 도구를 방해 할 수 있다면 버전 관리의 의견을 마샬링해야하는 두통에서 벗어날 수 있으며 "도구 사용"이라고 말할 수 있습니다. 개발 프로세스의 모든 구성원이 일반적으로 매우 순응하기 때문에.