C++ 프로젝트에서 버전을 유지 관리하는 좋은 방법은 무엇입니까?

Question

우리는 매월 수백 개의 SVN 개정판이있는 C++ 프로젝트를 운영하고 있습니다. 때로는 버전 번호에서 부 자리 숫자를 증가시켜 1.6에서 1.7로 변경해야 할 때도 있습니다. 한 달에 한 번 정도합니다. 올바른 접근 방법은 무엇입니까? 모든 새 버전에 변경 사항에 대한 정보를 저장/유지하고자하며 어떤 종류의 릴리스 정보를 원합니다. 제발, 우리에게 제안이나 링크를주세요. 감사!

ps. 죄송합니다 질문이 너무 막연한 경우.

pps. 질문을 조금 분명히해야한다는 것을 알았습니다. 나는 어떻게 버전을 명명해야하는지에 관심이 없다. 관심이 있어요 기술적으로 나는 C++ 코드에서 버전 번호를 유지해야한다.

Answer 1

'릴리스 노트'추적을 위해 일부 외부 도구를 사용하여 작업을 추적하는 것이 좋습니다. 기능을 할당하고 대부분의 경우 특정 서브 버전 커밋과 발행 번호를 연결할 수 있습니다. 나는 이것을 위해 ClearQuest와 Jira를 사용했지만, 오픈 소스/무료 툴이있다.

이 경로를 따르려면 각 커밋에 문제 번호가 태그되고 모든 문제에 특정 소프트웨어 버전 번호 ('해결 방법')가 태그로 지정되어 있는지 확인하십시오. 발견 된 각 버그에 대한 문제점을 엽니 다. 새로운 릴리즈가 나올 때마다 분기를 만들고 해당 릴리즈에서 해결할 문제로 태그 된 커밋을 병합하고 테스트합니다. 때로는이 릴리즈에서 의미가 아닌 변경 사항과 충돌 할 수 있습니다. 분기가 병합되고 빌드 및 테스트가 완료되면 분기 태그를 해제하십시오.

릴리스 문서를 생성하는 것은 매우 간단합니다. 모든 정보는 현재 릴리스 번호와 관련된 문제 추적기에 있습니다.

이전에도 다른 방법으로 수행 한 작업을 보았습니다. 개발 용 분기 열기, 분기에서 개별 변경 수행 및 트렁크로 다시 병합, 각 병합에는 전체 변경에 대한 설명 텍스트 포함 - 새로운 기능이나 버그가 수정되었습니다. 필요한 경우 트렁크에서 릴리스 태그를 직접 작성하십시오. 두 릴리스에서 변경 사항을 얻는 것은 한 릴리즈에서 다음 릴리스까지의 트렁크 변경 사항에서 로그를 읽는 것입니다.

두 가지 솔루션 모두 동일한 유형의 문제를 공유합니다. 병합은 이론 상 사소하지만 실제로는 그렇지 않습니다. 첫 번째 경우 트렁크에서 릴리스 분기로 코드를 가져올 때 중간 커밋을 가져 오지 않을 경우 병합 문제를 처리해야합니다. 브랜치에서 개발하고 트렁크로 다시 병합 할 때 트렁크에 병합하기 전에 먼저 트렁크 변경 사항을 브랜치에 병합해야합니다. 빌드하고 테스트 한 다음 트렁크로 다시 병합하십시오.

대부분의 전복 책은 두 번째 경로를 추천하지만 경우에 따라 처음 사용하는 책 (현재 사용하고있는 책)이 적합합니다. 이 경우에는 20 시간 이상 실행되는 자동화 된 테스트 세트가 있으며 트렁크에 직접 작성된 모든 코드는 자동 테스트 만 실행하면됩니다. 우리가 각각의 변화에 ​​대해 분기한다면, 우리가 다시 합칠 때까지 나뭇 가지를 테스트하지 않은 상태로 두거나, 테스트를 위해 더 많은 하드웨어를 던져야하고 개발 속도를 상당히 늦춰야 할 것입니다.

Answer 2

Semantic Versioning은 주/부 수정 목록 관리를위한 훌륭한 가이드 라인입니다. 그것을 사용하는 이점은 사람들에게 http://semver.org을 가리키게하여 버전 시스템을 완전히 이해할 수 있다는 것입니다.

Answer 3

은 내가 쓰는 모든 소프트웨어에 대해이 시스템을 사용

1.2.3.4 

1. 주요 버전 번호입니다. 많은 제품 기능을 변경하는 "주요"릴리스에서만 증가합니다.
2. 부 버전 번호. 정규 (분기 별, 월별) 릴리스 증가. 이 수는 9로 제한되지 않습니다. 너가 필요로하는만큼 높이 갈 자유롭게. 사소한 수정이나 업데이트의 경우이 값을 증가시키지 마십시오. 주 버전 번호가 변경되면이 번호는 0으로 설정됩니다.
3. 업데이트 번호입니다. 일련 번호를 업데이트 할 때마다이 번호를 증가시킵니다. 내 책의 업데이트는 일련의 버그 수정, 성능 향상 또는 보안 강화가 포함 된 릴리스로 간주됩니다. 이 값을 증가 시키려면 여러 변경 사항이 있어야합니다. 마이너 버전 번호가 변경되면 0으로 재설정됩니다.
4. 마이너 업데이트 번호. 사소한 개별 변경으로이 값을 증가시킵니다. 예를 들어 특정 버그를 수정하고 마지막 릴리스에 패치를 적용하면이 수가 증가합니다. 업데이트 번호가 변경되면이 번호를 0으로 재설정해야합니다.

마지막으로, 나는 시험판을 나타 내기 위해 다음 기호를 빌드를 사용

• B : 베타
• : 알파
• RC : 릴리스 후보

접미사 패키지가 빌드 될 시험판의 개정판을 나타내는 번호가 붙을 수 있습니다. 예 :

1.2.3.4b2 

은 두 번째 베타로 간주됩니다.

또한 버전을 쓸 때 후미 0을 제거 할 수 있습니다. 예 : 1.0.0.0은 1.0으로 작성 될 수 있습니다.

희망적으로 다소 유용합니다. 나는 그것이 조직 된 것을 유지하는 것을 돕고 나의 기록 보관소에 질서의 일부 유사를 유지하는 것을 발견했습니다.

Answer 4

당신은

• 수동으로 다음 configure 스크립트는
에 대한 config.h에 정의 PACKAGE_VERSION을 사용합니다 version.cc 파일
• 사용 GNU Autotools가를 유지하고 configure.in에 AC_INIT()에 버전 번호를 넣을 수 있습니다
• 태그를 사용하여 저장소에서 버전 번호를 범람하는 지점을 표시합니다. Subversion은 svn cp을 사용하여이를 수행합니다. 자세한 내용은 here
을 확인하십시오.210

Answer 5

버전 번호의 일부로 SVN 개정 번호를 포함하면 고객이 특정 빌드의 문제점을보고 한 것과 같이 관련 코드를 쉽게 체크 아웃 할 수있는 것처럼 매우 유용합니다. SVN 개정판을 쉽게 쿼리 할 수있는 스크립트를 작성할 수 있습니다 (예를 들어 JScript를 사용하여 스크립트를 작성했습니다). 자동으로 특수한 version.h 헤더를 작성합니다.메이저/마이너 숫자는 수동으로 유지되지만 나머지 두 숫자 (내 경우 SVN 개정 및 빌드 날짜를 나타내는 특수 빌드 번호)가 자동으로 작성됩니다. 그런 다음 MS Visual Studio 사전 빌드 단계를 사용하여 스크립트를 실행하여 모든 빌드에 최신 버전인지 확인합니다. 나는 자동 생성 헤더는 다음과 같이 뭔가를 찾고 끝 :

#ifndef VERSION_H 
#define VERSION_H 

namespace Version 
{ 
    const int MAJOR = 1; 
    const int MINOR = 2; 
    const int REVISION = 1234; 
    const int BUILD = 10123; 

    inline const char* toString() 
    { 
    return "1.2.1234.10123"; 
    } 

    ... 
} 

#endif 

간단히 명령 줄에서 svnversion을 실행 명령 줄에서 SVN 버전을 얻으려면.

Answer 6

WebKit 패치는 ReleaseNotes.txt 파일을 변경해야한다는 것을 알고 있습니다. 이것은 개인적인 변화를 추적하는 방법 일 수 있습니다.

이러한 작업에 도움이되는 많은 (WebKit 지향적 인) 스크립트가 있습니다. 그것들은 perl로 쓰여졌고 당신에게 유용한 비트를 가지고 있을지도 모릅니다.

http://trac.webkit.org/browser/trunk/WebKitTools/Scripts

체크 특히 - resolveChangelogs - svn-createpatch 가장 중요한 : prepare-changelogs

나는 스크립트에보고하지 않은,하지만 그들은 당신이 웹킷을 위해 무엇을해야 할 것 같다.