버전을 Major.Minor.Patch 숫자로 표기함
- 기존 버전과 호환되지 않게 API가 바뀌면 “Major(주) 버전”을 올리고,
- 기존 버전과 호환되면서 새로운 기능을 추가할 때는 “Minor(부) 버전”을 올리고,
- 기존 버전과 호환되면서 버그를 수정한 것이라면 “Patch(수) 버전”을 올린다.
Major.Minor.Patch 형식에 정식배포 전 버전이나 빌드 메타데이터를 위한 라벨을 덧붙이는 방법도 있다.
-
Major Version
- 이전 버전과 호환되지 않는 API 변경
- 증가할 경우 Minor, Patch 버전은 0으로 초기화
- 양수만 사용 가능
-
Minor Version
- 이전 버전과 호환되는 방식으로 새 기능 추가
- 새로운 기능이 추가된 API가 나왔지만, 기존의 공개된 API가 하위 호환되고 있을 때
- 기존의 기능이 변경되거나 사용방법이 변경 되었을 때
- 증가할 경우 Patch 버전은 0으로 초기화
- 양수만 사용 가능
-
Patch Version
- 이전 버전과 호환되는 방식으로 버그 등 수정
- 양수만 사용 가능
-
Pre-release Version
- 필요 시 사용
- ‘-’ 기호 뒤에 pre-release 버전 표기.
- 숫자 및 알파벳 대소문자 사용 가능.
- 동일 Patch Version보다 낮은 우선 순위를 가진다.
- ex)
2.1.1-alpha
, 2.1.1-alpha.1
-
Build Version
- 필요 시 사용
- ‘+’ 기호 뒤에 build 버전 표기.
- 숫자 및 알파벳 대소문자 사용 가능.
- 동일 Patch Version보다 높은 우선 순위를 가진다.
- ex)
1.0.0+120
, 1.0.0+exp.sha.511
, 1.0.0-alpha.1+build120
초기 개발 단계의 버전관리
-
초기 개발 단계에 0.y.z 버전 관리는 어떻게 할까?
가장 간단한 방법은 최초 개발 배포를 0.1.0으로 하고, 이후 배포마다 부버전을 올리는 것이다.
-
언제 1.0.0을 배포해야 할지 어떻게 알 수 있나?
소프트웨어가 실 서비스에 쓰이기 시작했다면 이미 1.0.0이라고 여길 수 있다. 사용자들이 믿고 쓸 수 있는 안정한 API가 있다면 1.0.0일 것이다. 하위 버전 호환성에 대해 우려하기 시작했다면 이미 1.0.0일 수 있다.
안드로이드 버전 관리 (versionCode와 versionName)