모범 사례 : 소프트웨어 버전 관리 [닫기]

여가 시간에 개발 한 소프트웨어를 재미있게 개발하는 방법에 대한 지침이나 표준 모범 사례가 있습니까? 나는 당신이 알고있는 버전 1에 대해 (예 : 버그 수정, 지원 등) 알 수 있도록 그러한 소프트웨어를 버전 화해야한다고 생각합니다.

그러나 버전 관리는 어디서 시작합니까? 0.0.0? 또는 0.0? 그런 다음 숫자를 늘리는 방법은 무엇입니까? 주요 릴리스. 사소한 변경? 버전 관리 시스템에 대한 커밋이 다른 버전이 아니어야합니까? 아니면 생산적인 방식으로 사용되는 버전에만 해당됩니까?

"릴리스"한 첫 번째 버전이 어떤 방식으로 불완전하다는 것을 알지 못하면 버전 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버전의 종류

x-주요 릴리스
y-부 릴리스
z-빌드 번호

기본적으로이 패턴을 따릅니다.

• 0.1.0에서 시작

• 준비가되면 소스 리포지토리, 코드 0.1.0에서 코드를 분기하고 0.1.0 분기를 생성하면 헤드 / 트렁크는 0.2.0 스냅 샷 또는 이와 비슷한 것이됩니다

• 트렁크에만 새로운 기능을 추가하지만 지점에 대한 백 포트 수정 사항과 시간이 지남에 따라 0.1.1, 0.1.2, ...

• 제품이 기능 완료로 간주되고 주요 단점이없는 경우 버전 1.0.0을 선언합니다.

• 그때부터-모든 사람이 메이저 버전을 증가시킬 때를 결정할 수 있습니다 ...

내 응용 프로그램에이 규칙을 사용합니다.

xyz

어디:

• x = 주 버전 번호, 1 ~
• y = 기능 번호, 0-9. 변경 사항에 버그 수정이 있거나없는 새로운 기능이 포함 된 경우이 수를 늘리십시오.
• z = 핫픽스 번호, 0 ~ 변경 사항에 버그 수정 만 포함 된 경우이 수를 늘리십시오.

예:

• 새 응용 프로그램의 경우 버전 번호는 1.0.0으로 시작합니다.
• 새 버전에 버그 수정 만 포함 된 경우 버전 번호가 1.0.1이되도록 핫픽스 번호를 늘리십시오.
• 새 버전에 버그 수정이 있거나없는 새 기능이 포함 된 경우 기능 번호를 늘리고 핫픽스 번호를 0으로 재설정하여 버전 번호가 1.1.0이되도록하십시오. 기능 번호가 9에 도달하면 기본 버전 번호를 늘리고 기능 및 핫픽스 번호를 0으로 재설정하십시오 (2.0.0 등).

우리는 abcd를 사용합니다.

• -전공 (고객에게 배송시 증가)
• b-미성년자 (고객에게 배송시 증가)
• c-개정 (내부 릴리스에서 증가)
• d-빌드 (크루즈 컨트롤에 의해 증가)

이 A.B.C접근법의 또 다른 예 는 Eclipse 번들 버전 관리 입니다. 이클립스 번들에는 네 번째 세그먼트가 있습니다.

Eclipse에서 버전 번호는 4 개의 세그먼트 (3 개의 정수 및 각각 이름이 지정된 문자열)로 구성됩니다 major.minor.service.qualifier. 각 세그먼트는 다른 의도를 포착합니다.

• 주요 세그먼트는 API의 파손을 나타냅니다
• 작은 부분은 "외부 적으로 보이는"변화를 나타냅니다
• 서비스 세그먼트는 버그 수정 및 개발 스트림 변경을 나타냅니다.
• 한정자 세그먼트는 특정 빌드를 나타냅니다

도있다 최신 버전 기법은 , 예를 들면 : YYYY.MM, YY.MM,YYYYMMDD

첫 번째 모습은 출시 날짜에 대한 인상을주기 때문에 상당히 유익합니다. 그러나 제품 수명주기에서 항상 정확한 지점을 알고 싶어하기 때문에 xyz 체계를 선호합니다 (Major.minor.release)

기본적인 대답은 "그것은 달려있다"입니다.

버전 관리의 목표는 무엇입니까? 많은 사람들이 version.revision.build를 사용하고 dev. 버전이 아닌 릴리스 버전이므로 version.revision을 전 세계에 광고합니다. 체크인 '버전'을 사용하면 버전 번호가 빠르게 커집니다.

프로젝트를 계획하는 경우 사소한 변경 사항이있는 릴리스의 개정판을 늘리고 주요 변경 사항, 버그 수정 또는 기능 / 기능이있는 릴리스의 증분 버전을 증분합니다. 베타 또는 야간 빌드 유형 릴리스를 제공하는 경우 버전을 확장하여 빌드를 포함하고 모든 릴리스마다 빌드를 늘리십시오.

아직도, 하루가 끝날 때, 그것은 당신에게 달려 있으며 그것은 당신에게 의미가 있습니다.

Mahesh가 말했듯이 : xyz 종류의 버전 관리를 사용합니다.

x-메이저 릴리스 y-마이너 릴리스 z-빌드 번호

z 대신 날짜 시간을 추가 할 수 있습니다.

다른 릴리스가 있으면 부 릴리스를 증가시킵니다. 주 릴리스는 아마도 0 또는 1로 유지 될 것입니다. 실제로 크게 변경하면 소프트웨어가 이전 릴리스와 이전 버전과 호환되지 않거나 전체 프레임 워크를 변경했을 때 변경됩니다.

당신은 항상 다른 사람들이 무엇을하고 있는지 확인할 수 있다는 것을 알고 있습니다. 오픈 소스 소프트웨어는 리포지토리에 액세스하는 경향이 있습니다. 예를 들어 SVN 브라우저가 http://svn.doctrine-project.org를 가리키고 실제 프로젝트에서 사용되는 버전 관리 시스템을 살펴볼 수 있습니다.

버전 번호, 태그, 모두 있습니다.

우리는 다음과 같은 abc 접근 방식을 따릅니다.

응용 프로그램에서 몇 가지 주요 변경 사항이있는 경우 무해한 'a'. .NET 1.1 응용 프로그램을 .NET 3.5로 업그레이드하는 것처럼

새로운 CR이나 Enhancement와 같은 사소한 변경 사항이있는 경우 무해한 'b'가 구현됩니다.

코드에 일부 결함이 수정되면 'c'는 무례합니다.

가장 낮은 (핫픽스가 아닌) segement에서 버전 관리를 시작합니다. 이 세그먼트를 10으로 제한하지 않습니다. 빌드를 추적하지 않는 한 증분을 적용 할 시점 을 결정하기 만하면 됩니다. QA 단계가있는 경우 가장 낮은 세그먼트에 증분을 적용한 다음 QA를 통과하고 릴리스 될 때 다음 단계가 증가합니다. 주요 동작 / UI 변경에 대한 최상위 세그먼트를 그대로 둡니다.

당신이 저와 같다면 당신은 그것을 소프트웨어의 진행 속도에 맞추기 위해 방법의 하이브리드로 만들 것입니다.

믹스에서 QA / 컴플라이언스가있는 경우 가장 많이 사용되는 패턴 abc 또는 abcd라고 생각합니다. 나는 주류를 위해 그것을 포기한 버전의 정규 부분이기 때문에 날짜가 너무 많았습니다.

빌드를 추적하지 않으므로 핫픽스가 포함되지 않은 경우 abc 패턴을 사용하고 싶습니다. 핫픽스를 적용해야하는 경우 시간이있는 날짜로 매개 변수 d를 적용합니다. 프로덕션에서 실제로 폭발 할 수있는 하루에 몇 명의 가능성이 항상 있기 때문에 시간 매개 변수를 d로 채택했습니다. 프로덕션 수정을 위해 분기 할 때 d 세그먼트 (YYYYMMDDHHNN) 만 적용합니다.

나는 개인적으로 va.b revc의 소프트웨어 체계에 반대하지 않을 것입니다. 여기서 c는 YYYYMMDDHHMM 또는 YYYYMMDD입니다.

그게 다야 당신은 그냥 할 수있는 경우 도구하다가 구성하는 방법과 실행은 마샬에 버전의 의견 패싯을 갖는 두통에서 당신을 유지하고 개발 과정에서 모든 사람들이 일반적이기 때문에 당신은 ... "도구를 사용하여"말할 수 있도록 준수 .