• ref

버전을 Major.Minor.Patch 숫자로 표기함

1. 기존 버전과 호환되지 않게 API가 바뀌면 “Major(주) 버전”을 올리고,
2. 기존 버전과 호환되면서 새로운 기능을 추가할 때는 “Minor(부) 버전”을 올리고,
3. 기존 버전과 호환되면서 버그를 수정한 것이라면 “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)