버전 관리 규칙

인터넷을 10분동안 뒤져보니 버전 넘버의 규칙은 "개발자 마음"이다

지 맘대로 규칙을 정하는 거다

하지만 제대로된 버전 넘버링 규칙이 없으면 버전 관리 자체가 귀찮을 뿐 아니라, 

개발자, 사용자 모두 버전으로부터 "이전 버전과 다르구나. 근데 뭐가 다르지?"란 의구심만 일으키고,

그러한 버전은 단순한 일렬번호 명시와 다를바가 없지 않을까?

버전이 프로그램 릴리즈의 모든 정보는 아니더라도 어떤 부분이 바뀌었다는 최소한의 정보를 알려주면 사용자/개발자 모두 아~주 좋아질 것이다

그럼 일단 다른 프로그램들의 버전 규칙을 보자

[1]. Linux/Windows/OS X의 규칙

http://java.tistory.com/16

[2]. 아파치의 버전관리에 관한 얘기

http://www.java2go.net/blog/163?TSSESSION=6394f9991cc2b87f1155f075496327fe

[2-1]. 아파치 문서

http://apr.apache.org/versioning.html

[3]. 버전에 대한 사전 지식

http://blueb.net/blog/576

뭐 여러 얘기가 있었지만 내 생각엔 아피치와 OS X의 경우가 제일 그럴싸하다

위 [2]문서에 적힌대로라면

"버전은 MAJOR.MINOR.PATCH의 전형적인 세쌍의 정수를 이용하여 표시된다. 기본적인 의도는 MAJOR 버전은 API에 호환되지 않는 대규모의 업그레이드를 수행한 것이며, MINOR 버전은 이전 마이너 버전과의 소스 및 바이너리 호환성은 유지한 것이고, PATCH 수준의 변경은 상하위 호환성을 완벽하게 유지한 버전이다."

이렇게 하는게 깔끔한거 같다

버전정보는 세 단위로 이루어지며,

MAJOR

아예 싹~ 바뀐 경우이다. 

대규모 업그레이드가 이루어진 경우이다

서버의 경우엔 클라이언트는 1.X.X으로의 접속 방식을 2.X.X에는 절대 접속 할 수 없다는 얘기다

MINOR

API 또는 기능에 변경이 발생되었을 경우이다

서버의 경우엔 기존 사용자들의 접속의 의사소통은 원할히 이루에 지지만, 몇몇 API가 추가/변경 되었거나 기능의 사용방법이 변경되었을 경우이다

소통은 원할히 이루어지지만 몇몇 기능들은 불가능 할 것이다

MINOR 버전이 변경되었을 경우엔 클라이언트에게 변경사항을 반드시 알려야 한다

PATCH

버그 수정의 경우

기존 클라이언트들은 접속과 수행에 아무런 변경사항을 느끼지 못한다. 2.1.3과 2.1.4를 동일한 방법으로 사용할 수 있다. 

하지만 서버 내부적으로는 버그가 수정되었거나, 내부적으로 소스가 수정되었다

그러나 클라이언트는 "뭔가 변경이 있었구나"정도로만 생각하면 될 뿐, 서버로의 접속에는 전혀 변경될 사항이 없다

이 버전은 현재 날짜를 써도 된다

버전은 

개발자 입장에서는 자신이 개발하는 프로그램의 현 시점을 알 수 있게 한다.

하지만 더욱 중요한건, 프로그램을 사용하는 입장에서는 어떤 사항이 이전 릴리즈와 다른지 대강의 정보를 알 수 있게 한다