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

Program / 글쓴이

여가 시간에 개발 한 소프트웨어를 재미있게 개발하는 방법에 대한 지침이나 표준 모범 사례가 있습니까? 나는 당신이 알고있는 버전 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)