Philip Withnall
philip.withnall@collabora.co.uk 2015
라이브러리 및 프로그램 버전 부여 및 출시
조성호
shcho@gnome.org 2016-2018.

# 버전 부여

#

        요약

        라이브러리와 프로그램의 모듈 버전 부여는 다릅니다. 라이브러리는 libtool 버전과 해당 패키지 버전이 필요합니다.  프로그램은 그냥 패키지 버전만 필요합니다.

          라이브러리와 프로그램은 major.minor.micro 형식의 패키지 버전을 보유합니다().
          라이브러리는 또한 current:revision:age 형식의 libtool 버전을 보유합니다().
          버전 번호는 매 출시 때마다(release 및 post-release 증가) 최신으로 유지해야합니다().
          패키지 버전은 기능의 바꾸거나 추가할 때 늘어나야합니다().
          libtool 버전은 API를 바꾸거나 추가할 때 최신으로 유지해야합니다().
          짝수/홀수 부 패키지 버전은 각각의 안정/불안정 출시판에 사용할 수 있습니다().

# 패키지 버전 부여

라이브러리 및 프로그램에는 주.부.세부 형식의 패키지 버전이 있습니다.

`AC_INIT()`에 전달하는 패키지 버전은 보통 프로젝트 버전으로 알려져 있습니다. 예를 들어 데비안 라이브러리 패키지는 (동시 설치가 가능한 패키지 이름의 주 버전 번호로) 라이브러리의 패키지 버전을 활용합니다. 패키지 버전은 다음 규칙을 따라 업데이트합니다:

라이브러리가 API 호환성을 깬다거나 프로그램에 전반적으로 영향(UI 재설계 등)을 주어 상당 부분이 바뀐다면, 주 버전 번호를 늘리고, 부 버전과 세부 버전을 0으로 설정합니다.

그렇지 않으면, 기능을 바꾸거나 추가할 경우, 또는 API를 추가할 경우 부 버전을 증가하고 마이크로 버전을 0으로 설정합니다.

그렇지 않으면(버그 수정 및 번역 업데이트가 들어간 출시작을 내보낼 경우), 마이크로 버전을 증가합니다.

참고로 부 버전 숫자는 API를 추가했을 경우 새로운 값으로 바꾸어야합니다.

# libtool 버전 부여

라이브러리에는 버전 번호가 두가지가 있습니다. ABI 이전 호환성을 따르는 libtool 버전( 참고), 그리고 기능의 바뀜을 따르는 패키지 버전으로 구성합니다. 보통 동기화 과정에서 증가하지만, ABI 이전 호환성은 기능의 바뀜 또는 버그 수정에 필연적 연관성이 없으므로 별도로 취급해야합니다. 게다가 두 버전 번호는 다른 관점을 가지고 있으며, 두 버전 번호를 활용하여 자동으로 만들 수 없습니다.

바람직한 libtool 버전 부여, 패키지 버전 부여 설명은 Autotools Mythbuster에 있습니다. 다른 내용은 libtool 설명서에 있습니다.

libtool 버전을 최신으로 바꾸려면, 다음 주석에 주어진 알고리즘을 따르십시오. libtool 버전 부여를 설정하는 configure.ac 일반 설정 부분입니다:

# Before making a release, the LT_VERSION string should be modified. The # string is of the form c:r:a. Follow these instructions sequentially: # 1. If the library source code has changed at all since the last update, then # increment revision (‘c:r:a’ becomes ‘c:r+1:a’). # 2. If any interfaces have been added, removed, or changed since the last # update, increment current, and set revision to 0. # 3. If any interfaces have been added since the last public release, then # increment age. # 4. If any interfaces have been removed or changed since the last public # release, then set age to 0. AC_SUBST([LT_VERSION],[0:0:0])

다음 부분은 Makefile.am에 사용하여 libtool로 버전 정보를 전달할 수 있습니다:

my_library_la_LDFLAGS = -version-info $(LT_VERSION)

# 안정 및 불안정 패키지 버전

대부분의 그놈 모듈은 안정 및 불안정 출시판의 형식을 따릅니다. 짝수 부 버전은 안정 출시판이며 홀수 부 버전은 불안정 출시판입니다. 예를 들어 3.20.* 버전은 안정 버전이지만, 3.19.* 버전은 불안정 버전입니다. 3.19.* 버전은 3.20 버전의 알파 출시판 및 베타 출시판이 될 수 있습니다.

새 마이크로 안정 버전(예: 3.20.0 → 3.20.1)에는 새 기능이 들어가지 않으며 번역 업데이트 및 버그 수정 사항만 들어갑니다. 반면에 불안정 마이크로 출시판(예: 3.19.1 → 3.19.2)에는 이전 마이너 집합의 마이크로 출시판에 대비하여 API를 추가하거나, 추가한 API를 바꾸고, 제거할 수 있습니다.

libtool 버전은 안정 패키지 버전에 따라서만 최신으로 바뀌어야합니다.

# 출시 절차

모듈의 출시 버전을 만드는 표준 절차는 출시를 진행할 때 libtool 버전(모듈이 라이브러리일 경우) 수를 증가한 후, 패키지 버전 번호를 증가합니다(이를 post-release 버전 증가라고 합니다).

출시 때의 libtool 버전 새로 고침은 출시 과정에서 모든 ABI가 바뀌었을 때만 증가함을 의미합니다. 패키지 버전에 post-release 방식을 사용함은 개발 기간동안 패키지 버전이(이전 출시판과 여전히 동일하게) 시기가 지나지 않음을 의미합니다.

출시 과정(GNOME 출시 과정 기반):

git pull 명령으로 코드가 최신인지 확인하십시오

git status 명령으로 로컬에 바뀐 내용이 있는지 확인하십시오

안정 패키지 버전 출시판이라면, configure.ac에서 libtool 버전 값(이 있는 경우)을 늘리십시오

NEWS 파일에 항목을 추가하십시오

./autogen.sh && make && make install && make distcheck 명령을 실행하고 성공했는지 확인하십시오

떠있는 문제를 고치고 바뀐 내용을 커밋한 다음 3단계에서 다시 시작하십시오

make distcheck 명령이 “[archive] is ready for distribution” 메시지로 끝났다면 git commit -a -m "Release version x.y.z"(‘x.y.z’는 패키지 버전 번호) 명령을 실행하십시오

git push를 실행하십시오

위 명령을 실행하는 동안 누군가가 이미 다른 커밋을 푸쉬하여 실패했다면, git pull 명령을 실행하여 우선 브랜치에 있는 여러분의 커밋과 병합한 후 git push 명령을 실행하십시오. 선형 Git 기록을 따르는 그놈 지침서의 예외 상황입니다(). 선형 기록을 따르는 방식을 선호한다면 1단계부터 다시 시작해야합니다.

git tag -s x.y.z(‘x.y.z’는 패키지 버전 번호) 명령으로 출시판에 태그를 부여하십시오

git push origin x.y.z(‘x.y.z’는 패키지 버전 번호) 명령을 실행하십시오

이제 출시 과정이 끝났으며, 출시 후 버전 증가 작업을 진행할 수 있습니다:

configure.ac의 패키지 버전 번호를 늘리십시오

git commit -a -m "Post-release version increment" 명령을 실행하십시오

git push를 실행하십시오

make distcheck 에서 만든 패키지 아카이브를 download.gnome.org으로 업로드 하든지 다른 수단으로 배포할 수 있습니다.