Version 관리 (Autotools 예시)

버전 정책 관리의 필요성


Autotools 뿐만 아니라 모든 라이브러리는 버전관리가 필수적입니다.

예를들어 내가 만든 라이브러리의 기존에 API가 삭제되었다면, 내가 만든 라이브러리를 사용하는 다른 누군가는 빌드에러가 발생하게 됩니다.

빌드에러가 발생하면 원인을 추적하는데에도 불필요한 시간이 소요되고 API가 삭제되었다면 그 라이브러리를 사용하기 위해서는 나의 소스를 다시 수정해야만 합니다.

따라서 라이브러리를 만들때에는 버전정보를 달아놓고, 기능변동이나 API변동에 따라 적절하게 버전을 수정해야합니다. 그래야만 나의 라이브러리를 사용하는 다른 사용자들이 버전정보를 보고 호환이 될 수 있다, 없다를 판단하여 사용할 수 있기 때문입니다.

버전관리의 기본 정책

버전관리의 기본 정책은 다음과 같습니다.
autotools은 version 정보가 'current:revision:age'로 되어있으며, 각 자리가 계산된 뒤에 라이브러리 뒤에 version으로 붙습니다.

릴리즈 전

릴리즈 전에는 내부 개발자간의 개발만 일어나게 됩니다.
따라서 불필요하게 버전이 자주 바뀌면 개발에 불편함이 있습니다.
릴리즈 전에는 아래와 같이 버전정보를 부여합니다.
libhello_la_LDFLAGS = \
    -version-info 0:0:0

1. 단순 소스가 수정된 경우

current : revision +1 : age

즉 라이브러리 버전으로는 아래와 같습니다.
libhello.so.0.0.0
-> 소스 수정
libhello.so.0.0.1
-> 소스 수정
libhello.so.0.0.2

2. Interface(user가 사용하게될 API)가 추가,변경,삭제된 경우

current+1 : 0 : age

즉 라이브러리 버전으로는 아래와 같습니다.
libhello.so.0.0.0
-> API 추가,변경,삭제
libhello.so.1.0.0
-> 소스 수정
libhello.so.0.1.1
-> API 추가,변경,삭제
libhello.so.2.0.0

릴리즈 후

릴리즈 후에는 이미 다른 사용자들이 라이브러리를 사용했기때문에 호환성을 고려해야합니다.

1. 소스 수정 (호환성 있음)

current : revision+1 : age

라이브러리 버전으로는 아래와 같습니다.
libhello.so.0.0.0
-> 소스 수정
libhello.so.0.0.1
-> 소스 수정
libhello.so.0.0.2

2. Interface 추가 (호환성 있음)

current+1 : 0 : age+1

라이브러리 버전으로는 아래와 같습니다.

libhello.so.0.0.0
-> API 추가
libhello.so.0.1.0
-> 소스 수정
libhello.so.0.1.1
-> API 추가
libhello.so.0.2.0

3. Interface 변경,삭제 (호환성 없음)

current+1 : 0 : 0

라이브러리 버전으로는 아래와 같습니다.

libhello.so.0.0.0
-> API 추가
libhello.so.0.1.0
-> 소스 수정
libhello.so.0.1.1
-> API 변경
libhello.so.1.0.0
-> API 제거
libhello.so.2.0.0

예제

1. 릴리즈 이후 interface가 추가된 경우
current와 age를 1 더하고 revision을 0으로 수정함 : -version-info 2:0:1
이 때 생성 된 lib : libhello.so.1.1.0

2. 이후 interface가 추가
current와 age를 1 더하고 revision을 0으로 수정함 : -version-info 3:0:2
이 때 생성 된 lib : libhello.so.1.2.0

3. 이 후 소스 수정
current / age는 유지하고 revision을 1 더함 : -version-info 3:1:2
이 때 생성 된 lib : libhello.so.1.2.1

4. 이후 interface 제거 또는 변경
current를 1 더하고 age, revision을 0으로 수정함 : -version-info 4:0:0
이 때 생성 된 lib : libhello.so.4.0.0

5. 이후 소스 수정
current / age는 유지하고 revision을 1 더함 : -version-info 4:1:0
이 때 생성 된 lib : libhello.so.4.0.1

기타

version 정책은 개발자마다 기준을 정해놓고 부여하면 됩니다. 

"릴리즈 전" 개발중에 맨 앞자리 lib가 계속 변경되어 혼란이 올 수도 있다는 의견이 많겠지만, version 정보는 매 commit마다 부여하는 것이 아닙니다.
일반적으로 version 정보는 아래와 같은 cycle을 보내야합니다.

'개발(여러 commit) -> version 발행 -> 검증'

즉, 여러 사람들이 개발하고 일정 주기가 되어 검증하여 내부적으로 버전정보를 발행합니다. 이렇게 된다면 불필요하게 버전정보가 쌓이는 일이 없게됩니다. 

"릴리즈 후"에는 일반적으로 interface가 변경되는 일이 많이 없습니다. 따라서 API 기준으로 version 정보를 발행하는것이 좋아보입니다.

"릴리즈 후"에 interface가 너무 많이 변경되거나 구조 자체가 변경되는 경우에는 일반적으로 version 정보를 초기화시킨 후 라이브러리 자체 버전을 부여합니다.

예) 
libhello.so.5.0.3
-> 릴리즈 이후 너무 많은것을이 변경될 예정
libhello2.so.0.0.0

오픈소스들은 이러한 정책들을 펼치기 때문에 심심치않게 소스뒤에 버전이 붙는것을 보실 수 있습니다.

예) bluez4, bluez5 / python2, python3 등..


*참고 : https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
등 기타 여러 사이트

댓글