버전 번호는 언제 증가시켜야합니까?

23

나는 학교에서 프로그래밍을 배우지 못했고 (전문) 개발자로 일하지 않기 때문에 많은 기본 사항이 명확하지 않습니다. 이 질문은 그들 중 하나를 명확히하려고합니다.

이제 내가 문제가 있다고 가정하자 #1, #2및 #3버전에 대한 개선 / 수정되도록 설정되어 내 문제 추적기에서 1.0.0마지막 (안정적) 버전입니다 0.9.0.

언제 버전으로 증분해야 1.0.0합니까? a) 위에 나열된 문제 중 하나만 종료되거나 b) 버전과 관련된 모든 문제 1.0가 종료 된 경우?

어느 하나 바로 그것을 할 수있는 방법은? 그리고 올바른 방법으로, 나는 현재 업계에서 사용되는 것을 의미합니다.

versioning semantic-versioning

— 아메드
소스

22

semver.org

— Martijn Pieters

1

그리고 다음 릴리스에도 세 가지 문제 를 모두 포함 할 수 있습니다.

— Martijn Pieters

예, 이미 SemVer를 사용하고 있으며 다음 릴리스에서는 세 가지 문제가 모두 해결 될 예정입니다.

— ahmed

혼란을 피하기 위해 질문을 편집했습니다.

— ahmed

14

직장에서 어떻게하는지 말해 줄 수 있습니다.

버전이 지정된 패키지를 빌드, 테스트, 태그 및 출력하는 지속적인 통합 서버가 있습니다. 이전 단계가 100 % 성공한 경우에만 다음 단계로 진행합니다.

우리의 버전은 <Major Version>. <Minor Version>. <Build Number>와 같습니다.

버그 수정이나 기능 향상이 완료되지 않은 모든 성공적인 빌드는 빌드 번호를 증가시킵니다.
버그 수정 또는 기능 향상이 완료된 모든 빌드는 부 버전을 증가시킵니다. 특정 형식을 사용하는 커밋 메시지가 있으면 자동으로 감지됩니다. 이 커밋 메시지는 프로젝트 ChangeLog에 자동으로 가져옵니다.
모든 주 버전 증분은 이전 버전과 호환되지 않는 변경 사항이 있거나 처음부터 다시 작성하거나 사례별로 작성된 다른 이유에 따라 수동으로 수행됩니다.

— 다이어트
소스

그러나 <Minor Version>에서 예를 들어 일련의 개선 사항이있는 경우 1.0.0입니다. 당신이해야합니까 ALL 최초의 향상이 완료로 "OK! 이제이 버전 1.0.0입니다"라고 할 수있는이 향상된 또는 자마자 버전 1.0.0로 증가?

— ahmed

@ahmed 나는 1.4.2"이 수정 프로그램들과 그 당시에 준비된 다른 것들" 이라는 접근 방식을 보았습니다. 또한 1.4.2"이것이 준비된 것이 있으면이 날짜에 릴리스 될 것"으로 보았습니다 . 릴리스주기에 따라 다릅니다.

5

@ahmed 0.xx에서 1.xx로가는 기준이 설정된 기능 / 수정의 완료 인 경우 모두 완료된 후에 만 증가합니다. 참고 : 우리는 전혀 그렇게 작동하지 않습니다. 우리는 버전을 대상으로하지 않으며 어떤 수정 프로그램이 포함되는지 결정합니다. 우리는 수정을 목표로 삼습니다. 우리가 얻는 버전은 순전히 목표가 아닌 추적 및 식별을위한 것입니다.

— dietbuddha 1

이것은 내가 알고 싶었던 것입니다 :)

— ahmed

21

버전 번호는 외부 사용자가 소프트웨어의 특정 빌드를 식별 할 수있는 방법이므로 릴리스 에만 관련 됩니다. 개발을 바쁘고 각 수정 프로그램을 개별적으로 발표하지 않는 경우 모든 수정 프로그램의 릴리스 번호를 늘릴 염려가 없습니다. 외부 사용자와 관련이 없으며 추가 버전 부기로 시간을 낭비합니다.

— 그렉 휴길
소스

릴리스가 사소한 버그에 대한 간단한 핫픽스 일 수있는 웹 개발에도 적용됩니까?

— ahmed

4

핫픽스를 발행하기 전에 QA를 수행합니까? 릴리스입니다. 전체 제품이 아닌 경우 핫픽스입니다.

— Peter K.

@ahmed 이러한 시나리오에서 버전 번호는 종종 사용자에게 보이지 않으므로 의미가 없습니다 (릴리스 번호는 주로 마케팅 및 기술 지원을 위해 존재하며 둘 다 많은 웹앱에는 적용되지 않음). 커밋 ID 만 사용하면 충분합니다. 버전 번호 사용을 고집한다면, 아마도 패치 레벨을 증가시킬 것입니다.

— amon

나는 많은 것을 배우고 있습니다 : p 그래서 요약하면 : 커밋 ID가 충분하기 때문에 버전 번호가 필요하지 않습니다. 모든 사용자는 어쨌든 마지막 버전을 사용하기 때문입니다.

— ahmed

2

모든 사용자가 동일한 버전을 사용하더라도 결함 보고서를 살펴볼 때 버전이 이동합니다. 보고서를 특정 소프트웨어 빌드에 연결하는 방법이 여전히 필요합니다 (날짜 / 시간이 충분할 수 있음).

— mattnz

2

지속적으로 배포되는 웹 응용 프로그램의 경우, 우리는 이전 버전과 빌드 번호 테일링을 사용하여 빌드 번호를 구성하는 경향이 있습니다. 일반적으로 숫자는 의도적 인 단계에 따라 숫자가 변경되지만 빌드 번호는 고유 한 고유 ID입니다.

여기에서하는 일은 배포 당일과 관련 svn 빌드 번호를 캡처하는 것입니다.

        <div id="svnrev">
            rev 2013.10.21.1078
        </div>

그만한 가치가 있습니다.

— 와이엇 바넷
소스

0

다른 답변은 이미 훌륭하므로 그 위에 추가 할 것입니다. 소프트웨어가 출시되지 않고 공개 버전 관리가 필요하지 않은 경우 (비공개 버전 관리는 VCS 임), 버전 끝에 " SNAPSHOT " 키워드를 추가하십시오 . 일부 시스템, 특히 종속성 관리의 경우 버전 번호 대신 스냅 샷의 변경 날짜를 비교한다는 점에서 스냅 샷을 릴리스 된 버전과 다르게 처리합니다. 따라서 패키지 저장소에 오전 8시 의 v. 1.0.0-SNAPSHOT v.이 있고 로컬 종속성 다운로더가 오전 7시와 동일한 버전을 가지고 있으면 저장소에서 업데이트 된 버전을 다운로드합니다.

위에서 언급했듯이 개인 버전 관리는 버전 제어 시스템 (git, svn 등)에서 제공합니다.

— 허버트 그제 스코 위크
소스

0

버전 관리 이론에 대한 충분한 언급이 있습니다. 여기에 다른 관점이 있습니다.

버전 1.0.0으로 언제 증가해야합니까?

주요 버전 번호 변경에 대한 답변에 중점을 둘 것입니다.

내 대답은 : 기본적으로 준비가되었을 때입니다. 0.9에서 1.0으로가는 것은 큰 문제입니다. 대중이 인식하기 때문에 베타 제품에서 공식 릴리스로 갈 것입니다.

(여기서는 회사의 상용 제품이라고 가정합니다).

0.9에서 1.0으로 가기 전에 몇 가지 질문이 있습니다.

조직에 현재 모든 고객에게 알리는 시간이 있습니까? 파티를 열다. 많은 지원 요청을 받으십시오. 제품을 판매하는 계정 관리자? 등

예, 버전 관리를 마케팅 도구로보고 주변을 둘러 보면 기본적으로 업계 표준이라는 것을 알 수 있습니다.

우리 회사는 버전 2.x에서 3.0으로 갔고 멋진 파티를 열었고 많은 버즈를 만들었고 그로 인해 새로운 고객이 많았습니다. 일부 인터페이스 업데이트 외에도 버전 간의 차이는 매우 작습니다.

— 피터 B
소스