Tiny Logs 

일반적인 버전(version) 관리 규칙

타이니 | 2012.07.17 17:20 | 조회 8,331
카테고리분류 : 기타 항목
Versions from Doug Coupland's Novel jPod


일반적으로 사용되는 버전(version) 관리 규칙을 나름대로 정리했습니다.
가끔 규칙성 없이 사용하시는 분들이 계시는데 통일하시면 좋습니다. 뭐... 꼭 이게 정해진 표준 같은 것은 아닙니다. 제가 사용하는 규칙이면서 가장 많이 범용화 된 룰이기도 합니다.


1. 가장 많이 쓰는 버전의 자리 수는 3자리 수이며 모두 음수가 아닌 정수입니다. 또한 각각의 자리 수는 1 단위로 수치 증가합니다.

예) 1.0.11 -> 1.0.12 -> 1.1.0 -> 1.2.0 -> 1.2.1 -> 2.0.0
해석) 초기 버전 (1.0.0)에서 11번의 패치가 이루어진 1.0.11 버전에서 12번째 패치가 이루어져 1.0.12 버전이 되었습니다. -> 패치 수준을 넘어선 수정을 했거나 그동안의 패치를 리펙토링해서 1.2.0 으로 부 버전 변경을 했습니다. -> 패치가 이루어져 1.2.1 버전이 되었습니다 -> 하위 버전과의 호환을 담보하지 못 할 수준의 큰 변경이 되어 주 버전이 증가해 2.0.0 을 공개합니다.


2. 3자리 수 기준으로 각 자리 수의 의미는 다음과 같습니다.

버전 1.0.0 에서 각 자리 수를 영문자 X.Y.Z 이라 할 때.

X 는 주 버전입니다.
Y 는 부 버전입니다.
Z 는 패치 버전입니다.


3. 버전의 상위 자리 수가 증가하면 하위 자리 수의 수치는 0 으로 재설정 해야 합니다.

예) 1.1.9 -> 2.0.0   또는   2.0.4 -> 2.1.0


4. 일반적으로 버전 1.0.0 은 첫 정식 공개 시의 버전을 의미합니다.

첫 공개 이전 내부적으로는 0.0.0 으로 시작하는 버전을 사용합니다.


5. 세번째 자리 수(패치버전)인 Z 부분의 수치 증가는 하위 동일한 주 / 부 버전내에서 완벽히 하위 호환을 해야 합니다. 또한 있던 기능의 수정이 아닌 새로운 기능의 추가일 경우 패치 버전(Z)이 아닌 부 버전(Y)의 수치 증가를 고려함이 옳습니다.

예) 버전 1.1.12 에서 있던 기능의 문제점을 수정한 1.1.13 버전을 만들었다면 1.1.0 버전 ~ 1.1.12 버전까지는 완벽히 서로 호환되어야 한다.


6. 두번째 자리 수(부버전)인 Y 부분의 수치 증가는 패치 수준의 업데이트들을 모아 리펙토링 정비하고 출시할 때 사용하거나 패치 수준이 아닌 없던 기능 추가를 포함한 업데이트일 때 수치 증가합니다. 이 때 Z 부분의 수치를 0 으로 초기화 합니다. 하위 호환의 경우 동일한 주 버전내에서 완벽히 또는 사용자의 수동 작업에 의해 일부 가능해야 함이 옳고 충분히 안내를 해야합니다.

예) 버전 1.1.13 에서 그동안의 패치를 리펙토링 하고 몇가지 기능을 추가해 1.2.0 버전을 만들었다면 1.0.0 버전 ~ 1.1.13 버전까지는 별도의 작업없이 완벽히 호환하거나 몇가지 사용자의 수동 작업만으로 서로 호환되어야 한다.


7. 첫번째 자리 수(주버전)인 X 부분의 수치 증가는 하위 버전과 호환되지 않는 (또는 호환방법을 공식적으로 안내하지 않는) 수준의 변경 및 업데이트가 되었을 때 수치 증가합니다. 이 때 부 버전과 패치 버전인 Y와 Z 수치를 0으로 초기화 합니다.

예) 버전 1.2.0 에서 큰 수준의 로직 변경과 기능 추가를 했는데 하위 버전과의 호환성을 간단한 수정만으로 장담할 수 없을 정도라서 주 버전 수치를 증가해 버전 2.0.0 을 출시하고 공식적인 하위버전과의 호환방법을 제공하지 않고 프로그램 교체를 권했다.


8. 시험판 버전은 - (대시)를 사용하며 alpha 와 beta 를 주로 씁니다. 알파는 공개되지 않은 내부 버전이며 베타는 공개된 버전이지만 정식 버전은 아닌 상태를 뜻합니다. alpha와 beta 뒤에 수치를 적어 세분화 할 수 있습니다.

예) 1.0.0-alpha -> 1.0.0-beta (이때부터 사람들이 다운받아 설치해 볼 수 있음) -> 1.0.0-beta2 -> 1.0.0 (정식버전)



이렇게 버전 관리 규칙을 정하고 시행한다면 개발자는 당연히 개발과정의 체계성을 향상시킬 수 있고요.
사용자도 아래의 예시처럼 버전만 보더라도 업그레이드 관련 여러 정보를 얻을 수 있습니다.

예) 사용자인 나는 게시판 모듈의 버전 1.0.7 을 사용하고 있다.
우연히 업데이트를 확인하니 게시판 1.0.12 버전이 공개되어 있다. 세 번째 자리수가 7에서 12로 수치 증가했으니 그동안 5번의 패치가 있었나보다. 패치 버전이니 게시판 디비나 기능의 변경 등 큰 변경이 없고 버전 첫번째 자리수와 두번째 자리수도 같으니 완벽히 하위 호환성을 유지하나 보다. 부담없이 덮어씌워 업데이트 고고씽~

예) 사용자인 나는 게시판 모듈의 버전 1.0.12 를 사용하고 있다.
우연히 업데이트를 확인하니 게시판 1.1.0 버전이 공개되어 있다. 두 번째 자리수인 부 버전 수치가 올라갔으니 그냥 덮어씌우면 되는게 아니라 업데이트 시 고려해야 할 게 있나보다. 뭐가 업데이트 된건지... 제대로 하위 호환성을 유지하며 업데이트 하려면 어떻게 해야 하는지 도움말을 찾아 살펴보고 업데이트할지 결정해야겠다.

예) 사용자인 나는 게시판 모듈의 버전 1.1.0 을 사용하고 있다.
우연히 업데이트를 확인하니 게시판 2.0.0 버전이 공개되어 있다. 첫 번째 자리수인 주 버전 수치가 올라갔으니 하위호환성을 보장하지 않는가보다. 게시판의 디비구조가 바꼈든지 중요한 로직이 바뀌었다면, 업데이트 이후 기존에 쌓여있던 게시물에 이상이 생길 것이다. 나는 현재 게시판 모듈 사용에 불만이 없으니 업데이트 하지 말아야겠다. 또는 새 버전의 장점과 추가된 기능을 검토해보고 업데이트 필요성이 있다면 기존 데이터의 마이그레이션을 위한 의뢰/작업일정을 잡아서 추진해야겠다.


이상입니다. 개발자 / 사용자 모두 슬쩍 읽어보시고 보통은 버전 번호에 이런 룰이 있구나 라고 알아두시면 좋겠습니다.
크리에이티브 커먼즈 라이선스
22개(1/3페이지) rss


많이 본 글최근 90일내 많이 본 글입니다.
댓글 많은 글최근 90일내 댓글 많은 글입니다.
Tag Cloud
등록된 태그가 없습니다.

Visits Counter
  • 29오늘 방문
  • 96어제 방문
  • 29오늘 페이지뷰
  • 97어제 페이지뷰
  • 2,619이번 달 방문
  • 2,247지난 달 방문