나는 학교에서 프로그래밍을 배우지 못했고 (전문) 개발자로 일하지 않기 때문에 많은 기본 사항이 명확하지 않습니다. 이 질문은 그들 중 하나를 명확히하려고합니다.
이제 내가 문제가 있다고 가정하자 #1, #2및 #3버전에 대한 개선 / 수정되도록 설정되어 내 문제 추적기에서 1.0.0마지막 (안정적) 버전입니다 0.9.0.
언제 버전으로 증분해야 1.0.0합니까? a) 위에 나열된 문제 중 하나만 종료되거나 b) 버전과 관련된 모든 문제 1.0가 종료 된 경우?
어느 하나 바로 그것을 할 수있는 방법은? 그리고 올바른 방법으로, 나는 현재 업계에서 사용되는 것을 의미합니다.
답변
직장에서 어떻게하는지 말해 줄 수 있습니다.
버전이 지정된 패키지를 빌드, 테스트, 태그 및 출력하는 지속적인 통합 서버가 있습니다. 이전 단계가 100 % 성공한 경우에만 다음 단계로 진행합니다.
우리의 버전은 <Major Version>. <Minor Version>. <Build Number>와 같습니다.
- 버그 수정이나 기능 향상이 완료되지 않은 모든 성공적인 빌드는 빌드 번호를 증가시킵니다.
- 버그 수정 또는 기능 향상이 완료된 모든 빌드는 부 버전을 증가시킵니다. 특정 형식을 사용하는 커밋 메시지가 있으면 자동으로 감지됩니다. 이 커밋 메시지는 프로젝트 ChangeLog에 자동으로 가져옵니다.
- 모든 주 버전 증분은 이전 버전과 호환되지 않는 변경 사항이 있거나 처음부터 다시 작성하거나 사례별로 작성된 다른 이유에 따라 수동으로 수행됩니다.
답변
버전 번호는 외부 사용자가 소프트웨어의 특정 빌드를 식별 할 수있는 방법이므로 릴리스 에만 관련 됩니다. 개발을 바쁘고 각 수정 프로그램을 개별적으로 발표하지 않는 경우 모든 수정 프로그램의 릴리스 번호를 늘릴 염려가 없습니다. 외부 사용자와 관련이 없으며 추가 버전 부기로 시간을 낭비합니다.
답변
지속적으로 배포되는 웹 응용 프로그램의 경우, 우리는 이전 버전과 빌드 번호 테일링을 사용하여 빌드 번호를 구성하는 경향이 있습니다. 일반적으로 숫자는 의도적 인 단계에 따라 숫자가 변경되지만 빌드 번호는 고유 한 고유 ID입니다.
여기에서하는 일은 배포 당일과 관련 svn 빌드 번호를 캡처하는 것입니다.
<div id="svnrev">
rev 2013.10.21.1078
</div>
그만한 가치가 있습니다.
답변
다른 답변은 이미 훌륭하므로 그 위에 추가 할 것입니다. 소프트웨어가 출시되지 않고 공개 버전 관리가 필요하지 않은 경우 (비공개 버전 관리는 VCS 임), 버전 끝에 ” SNAPSHOT ” 키워드를 추가하십시오 . 일부 시스템, 특히 종속성 관리의 경우 버전 번호 대신 스냅 샷의 변경 날짜를 비교한다는 점에서 스냅 샷을 릴리스 된 버전과 다르게 처리합니다. 따라서 패키지 저장소에 오전 8시 의 v. 1.0.0-SNAPSHOT v.이 있고 로컬 종속성 다운로더가 오전 7시와 동일한 버전을 가지고 있으면 저장소에서 업데이트 된 버전을 다운로드합니다.
위에서 언급했듯이 개인 버전 관리는 버전 제어 시스템 (git, svn 등)에서 제공합니다.
답변
버전 관리 이론에 대한 충분한 언급이 있습니다. 여기에 다른 관점이 있습니다.
버전 1.0.0으로 언제 증가해야합니까?
주요 버전 번호 변경에 대한 답변에 중점을 둘 것입니다.
내 대답은 : 기본적으로 준비가되었을 때입니다. 0.9에서 1.0으로가는 것은 큰 문제입니다. 대중이 인식하기 때문에 베타 제품에서 공식 릴리스로 갈 것입니다.
(여기서는 회사의 상용 제품이라고 가정합니다).
0.9에서 1.0으로 가기 전에 몇 가지 질문이 있습니다.
조직에 현재 모든 고객에게 알리는 시간이 있습니까? 파티를 열다. 많은 지원 요청을 받으십시오. 제품을 판매하는 계정 관리자? 등
예, 버전 관리를 마케팅 도구로보고 주변을 둘러 보면 기본적으로 업계 표준이라는 것을 알 수 있습니다.
우리 회사는 버전 2.x에서 3.0으로 갔고 멋진 파티를 열었고 많은 버즈를 만들었고 그로 인해 새로운 고객이 많았습니다. 일부 인터페이스 업데이트 외에도 버전 간의 차이는 매우 작습니다.