나는 현재 친구를 위해 작은 데스크탑 응용 프로그램을 작성하고 있지만, 나는 주로 나 자신을위한 학습 경험으로하고 있습니다. 교육 받고 올바른 일을하는 정신으로이 앱의 버전 번호를 갖고 싶습니다.
내 연구는 이러한 관련 결과를 가져 왔습니다
그러나 이들 중 어느 것도 알파, 베타, 출시 후보 등의 번호 매기기를 다루지 않습니다. 1.0 이하의 버전 번호에 대한 규칙은 무엇입니까? 나는 그들이 한동안 갈 수 있다는 것을 안다. 예를 들어, PuTTY는 최소 10 년 동안 사용되었으며 여전히 베타 0.60 버전입니다.
답변:
그것은 실제로 프로젝트에 달려 있습니다. 일부 프로젝트는 버전 1.0도 릴리스하지 않습니다.
MAME 개발자는 에뮬레이터 프로그램 버전 1.0을 출시하려고하지 않습니다. 논쟁은 항상 더 많은 아케이드 게임이 있기 때문에 진정한 "완성"이 될 수 없다는 것입니다. 버전 0.99에 이어 버전 0.100 (부 버전 100> 99)이 이어졌습니다. 비슷한 방식으로 Xfire 1.99 다음에 1.100이있었습니다. 6 년간의 개발 끝에 eMule은 아직 0.50 버전에 도달하지 못했습니다. Wikipedia의 소프트웨어 버전 관리
사용하기 시작한 버전 번호 매기기 방법 중 하나는 Semantic Versioning 입니다.
이 체계에서 버전 번호와 변경 방법은 기본 코드와 한 버전에서 다음 버전으로 수정 된 내용에 대한 의미를 전달합니다.
작동 방식 및 / 또는 일부 질문에 대한 추가 아이디어를 제공하는 인용문 :
1.0.0 출시시기를 어떻게 알 수 있습니까?
소프트웨어를 프로덕션 환경에서 사용중인 경우 이미 1.0.0이어야합니다. 사용자가 의존하게 된 안정적인 API가 있다면 1.0.0이어야합니다. 이전 버전과의 호환성에 대해 걱정이된다면 이미 1.0.0 일 것입니다.
이것이 빠른 개발과 빠른 반복을 방해하지 않습니까?
주요 버전 0은 빠른 개발에 관한 것입니다. 매일 API를 변경하는 경우 여전히 버전 0.xx 또는 다음 주요 버전에서 작동하는 별도의 개발 브랜치에 있어야합니다.
아주 작은 이전 버전과의 호환되지 않는 공개 API 변경에도 큰 버전 충돌이 필요한 경우 버전 42.0.0에서 매우 빠르게 끝나지 않습니까?
이것은 책임감있는 개발과 예측의 문제입니다. 종속 코드가 많은 소프트웨어에는 호환되지 않는 변경 사항을 가볍게 도입해서는 안됩니다. 업그레이드에 소요되는 비용은 상당 할 수 있습니다. 호환되지 않는 변경 사항을 릴리스하기 위해 주요 버전을 충돌해야한다는 것은 변경 사항의 영향을 생각하고 관련 비용 / 혜택 비율을 평가한다는 것을 의미합니다.
"알파", "베타"등의 릴리스를 지정하는 방법에 대한 규칙도 있습니다. 자세한 내용은 http://semver.org/ 에서 확인 하십시오 .
[편집] 또 다른 흥미로운 버전 번호 체계는 MongoDB가 사용하는 것입니다 .
MongoDB는 개발 릴리스에 홀수 번호 버전을 사용합니다.
MongoDB 버전에는 3 개의 숫자가 있습니다 : ABC
- A는 주요 버전입니다. 이것은 거의 변하지 않으며 매우 큰 변화를 나타냅니다.
- B는 릴리스 번호입니다. 여기에는 이전 버전과의 호환성을 손상시킬 수있는 기능 및 사항을 포함한 많은 변경 사항이 포함됩니다. B조차도 안정적인 브랜치가되고 홀수 B는 개발이 될 것입니다.
- C는 개정 번호이며 버그 및 보안 문제에 사용됩니다.
예를 들면 다음과 같습니다.
- 1.0.0 : 첫 번째 GA 릴리스
- 1.0.x : 1.0.x 버그 수정-업그레이드를 적극 권장합니다.
- 1.1.x : 개발 릴리스. 여기에는 완전히 완료되지 않은 진행중인 새로운 기능이 포함됩니다. 1.0과 다른 것이있을 수 있습니다
- 1.2.x : 두 번째 GA 릴리스. 이것은 1.1.x 릴리스의 정점이 될 것입니다.
나는 "표준"이 있다고 생각하지 않습니다.
릴리스 후보에 대한 규칙은 일반적으로 릴리스 할 것으로 생각되는 버전 수에 따라 "[버전] RC 1"등입니다.
기능이 완전하지 않은 초기 버전의 제품을 출시하는 경우 "0"버전을 사용하는 것이 좋습니다. 이렇게하면 기능 세트를 작성할 때 시간이 지남에 따라 버전을 증가시킬 수 있습니다.
Release Candidate와 같은 "Alpha"와 "Beta"를 사용합니다. 시간 제한 버전은 정식 버전 출시에 가깝다고 생각합니다.
Software Versioning 에 Wikipedia 페이지가 있습니다 . 1.0 이전 버전을 공유하는 경우 Apple 및 기타 업체에서 사용하는 규칙이 잘 작동합니다. major.minor.maintSrev 여기서 S는 시험판 버전의 단계 표시기입니다 : d = development, a = alpha, b = beta, rc = release 후보. 따라서 첫 번째 내부 버전은 1.0.0d1이 될 수 있습니다.
완전히 내부 개정하려면 타임 스탬프이면 충분합니다.
대부분의 각 개발자는 어떤 표준을 사용할 것인지 결정합니다. 일반적으로 소수점 왼쪽의 숫자는 일반 사용자에게 매우 눈에 띄는 큰 개정판을 나타냅니다 (예 : 기능 또는 인터페이스 변경 등). 소수점 오른쪽에 이것은 전체 기능과 디자인을 많이 바꾸지 않았지만 프로그램 자체에 대해 무언가를 변경 한 변경 / 수정 / 추가입니다. 보안 문제). 그런 다음 소수점을 더 추가하면 오른쪽에있는 숫자가 점점 더 작아지고 작은 변화 (예 : 사소한 버그 수정 / 보안 문제 등)를 나타냅니다.
다른 사람들이 말했듯이 정확한 표준은없는 것 같습니다. 우리 조직은 다음 표기법을 사용합니다.
릴리스 1.0 ---> 2.0 (제품에 새로 추가 된 주요 기능)
릴리스 1.0 ---> 1.1 (제품에 추가 된 중간 수준의 새로운 기능 / 개선 된 기능)
릴리스 1.0 ---> 1.001 (버그)
"버전 1.0"마일스톤은 숙련 된 컴퓨터 사용자에게 매우 중요합니다. 프로그램이 완료 되어 예상대로 작동 한다는 것을 의미합니다 . "0.something"버전의 모든 것은 프로그래머가 프로그램이 아직 완료 되지 않았다고 생각한다는 것을 의미합니다 .
기능의 주요 성과를 위해 "0.1", "0.2"... 버전 번호를 유지 한 다음 자주 세분화 된 날짜 및 타임 스탬프 인 빌드 번호로 하위 세트를 지정할 수 있습니다.