버전 관리

버전 관리 (Versioning)

이 페이지에서는 Druid가 버전을 어떻게 관리하는지, 그리고 안정 릴리스에 대한 정보를 설명해 드려요.

출처: 문서

본문

버전 관리 전략 (Versioning Strategy)

Druid는 일반적으로 시맨틱 버저닝(semantic versioning)을 따릅니다. 기본 개념은 다음과 같아요.

  • "Major" 버전(가장 왼쪽 값): 하위 호환이 없는 버전이에요. 버전 간에는 API에 대한 어떤 보장도 없습니다.
  • "Minor" 버전(가운데 숫자): 작은 숫자에서 큰 숫자로는 앞으로 이동할 수 있지만, 거꾸로(하위 버전으로) 이동하면 호환이 깨질 수 있어요.
  • "bug-fix" 버전("patch" 또는 가장 오른쪽 값): 서로 교체 가능한 버전이에요. 숫자가 높을수록 더 많은 것이 수정됐다고 보면 되고, 프로그래밍 인터페이스는 완전히 호환되므로 새 jar 파일을 그대로 교체해도 동작합니다.

여기서 호환 기준은 '기능'이 아니라 '프로그래밍 API'라는 점을 기억해 두세요. 공개 API에 추가되거나 변경되는 게 없다면, 'bug-fix' 릴리스에서 아주 멋진 새로운 기능이 도입될 수도 있어요.

지금은 아직 major 버전 0 단계라 예외가 하나 있습니다. 이 기간에는 API를 베타로 간주하고 "major"와 "minor"를 함께 취급해서, major 버전 0인 동안에는 minor 버전 증가가 하위 호환을 깨뜨릴 수도 있어요. 이런 변경은 그룹 메일을 통해 공지됩니다.

외부 배포의 경우 안정 릴리스(stable release) 태그를 사용할 것을 권장해요. 릴리스를 실제 프로덕션 환경에 배포하고 한동안 버그 없이 운영한 뒤에야 안정 릴리스로 간주합니다.

태깅 전략 (Tagging strategy)

코드베이스의 태그는 릴리스 후보(release candidate)와 동일해요. Druid는 릴리스 프로세스(QA 사이클과 배포를 포함)를 진행할 때마다 코드에 태그를 답니다. 그러니 태그 하나를 '안정 릴리스'라고 단정하기는 어렵고, 프로덕션 QA 사이클과 배포 과정을 거치며 코드가 굳어져 가는 단계라고 보는 게 맞아요. 태그는 절대 바뀌지 않지만, 실제로 안정 릴리스가 프로덕션에 올라가기 전까지 여러 번 태그를 반복하는 경우가 많습니다. 태그에 뭐가 들어 있는지 잘 모르겠다면, Release 페이지에 나열된 안정 릴리스를 사용하는 걸 권장해요.

더 알아보기 (Learn more)