Blob Blame History Raw
<?xml version="1.0" encoding="utf-8"?>
<page xmlns="http://projectmallard.org/1.0/" xmlns:its="http://www.w3.org/2005/11/its" type="topic" id="versioning" xml:lang="ko">

  <info>
    <link type="guide" xref="index#maintainer-guidelines"/>

    <credit type="author copyright">
      <name>Philip Withnall</name>
      <email its:translate="no">philip.withnall@collabora.co.uk</email>
      <years>2015</years>
    </credit>

    <include xmlns="http://www.w3.org/2001/XInclude" href="cc-by-sa-3-0.xml"/>

    <desc>라이브러리 및 프로그램 버전 부여 및 출시</desc>
  
    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
      <mal:name>조성호</mal:name>
      <mal:email>shcho@gnome.org</mal:email>
      <mal:years>2016, 2017.</mal:years>
    </mal:credit>
  </info>

  <title>버전 부여</title>

  <synopsis>
    <title>요약</title>

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

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

  <section id="package-versioning">
    <title>패키지 버전 부여</title>

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

    <p><code>AC_INIT()</code>에 전달하는 패키지 버전은 보통 프로젝트 버전으로 알려져 있습니다. 예를 들어 데비안 라이브러리 패키지는 (<link xref="parallel-installability">동시 설치</link>가 가능한 패키지 이름의 주 버전 번호로) 라이브러리의 패키지 버전을 활용합니다. 패키지 버전은 다음 규칙을 따라 업데이트합니다:</p>
    <steps>
      <item><p>라이브러리가 <link xref="api-stability">API 호환성</link>을 깬다거나 프로그램에 전반적으로 영향(UI 재설계 등)을 주어 상당 부분이 바뀐다면, 주 버전 번호를 늘리고, 부 버전과 세부 버전을 0으로 설정합니다.</p></item>
      <item><p>그렇지 않으면, 기능을 바꾸거나 추가할 경우, 또는 API를 추가할 경우 부 버전을 증가하고 마이크로 버전을 0으로 설정합니다.</p></item>
      <item><p>그렇지 않으면(버그 수정 및 번역 업데이트가 들어간 출시작을 내보낼 경우), 마이크로 버전을 증가합니다.</p></item>
    </steps>

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

  <section id="libtool-versioning">
    <title>libtool 버전 부여</title>

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

    <p>바람직한 libtool 버전 부여, 패키지 버전 부여 설명은 <link href="https://autotools.io/libtool/version.html">Autotools Mythbuster</link>에 있습니다. 다른 내용은 <link href="http://www.gnu.org/s/libtool/manual/html_node/Updating-version-info.html">libtool 설명서</link>에 있습니다.</p>

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

    <code>
# 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])</code>

    <p>다음 부분은 <file>Makefile.am</file>에 사용하여 libtool로 버전 정보를 전달할 수 있습니다:</p>
    <code>my_library_la_LDFLAGS = -version-info $(LT_VERSION)</code>
  </section>

  <section id="stable-unstable-versions">
    <title>안정 및 불안정 패키지 버전</title>

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

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

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

  <section id="release-process">
    <title>출시 절차</title>

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

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

    <p>출시 과정(<link href="https://wiki.gnome.org/MaintainersCorner/Releasing">GNOME 출시 과정</link> 기반):</p>
    <steps>
      <item><p><cmd>git pull</cmd> 명령으로 코드가 최신인지 확인하십시오</p></item>

      <item><p><cmd>git status</cmd> 명령으로 로컬에 바뀐 내용이 있는지 확인하십시오</p></item>
      <item><p>안정 패키지 버전 출시판이라면, <file>configure.ac</file>에서 libtool 버전 값(이 있는 경우)을 늘리십시오</p></item>
      <item><p><file>NEWS</file> 파일에 항목을 추가하십시오</p></item>
      <item>
        <p><cmd>./autogen.sh &amp;&amp; make &amp;&amp; make install &amp;&amp; make distcheck</cmd> 명령을 실행하고 성공했는지 확인하십시오</p>
        <list>
          <item><p>떠있는 문제를 고치고 바뀐 내용을 커밋한 다음 3단계에서 다시 시작하십시오</p></item>
        </list>
      </item>
      <item><p><cmd>make distcheck</cmd> 명령이 “[archive] is ready for distribution” 메시지로 끝났다면 <cmd>git commit -a -m "Release version x.y.z"</cmd>(‘x.y.z’는 패키지 버전 번호) 명령을 실행하십시오</p></item>
      <item>
        <p><cmd>git push</cmd>를 실행하십시오</p>
        <list>
          <item><p>위 명령을 실행하는 동안 누군가가 이미 다른 커밋을 푸쉬하여 실패했다면, <cmd>git pull</cmd> 명령을 실행하여 우선 브랜치에 있는 여러분의 커밋과 병합한 후 <cmd>git push</cmd> 명령을 실행하십시오. 선형 Git 기록을 따르는 그놈 지침서의 예외 상황입니다(<link xref="version-control#use-of-git"/>). 선형 기록을 따르는 방식을 선호한다면 1단계부터 다시 시작해야합니다.</p></item>
        </list>
      </item>
      <item><p><cmd>git tag -s x.y.z</cmd>(‘x.y.z’는 패키지 버전 번호) 명령으로 출시판에 태그를 부여하십시오</p></item>
      <item><p><cmd>git push origin x.y.z</cmd>(‘x.y.z’는 패키지 버전 번호) 명령을 실행하십시오</p></item>
    </steps>

    <p>이제 출시 과정이 끝났으며, 출시 후 버전 증가 작업을 진행할 수 있습니다:</p>
    <steps>
      <item><p><file>configure.ac</file>의 패키지 버전 번호를 늘리십시오</p></item>
      <item><p><cmd>git commit -a -m "Post-release version increment"</cmd> 명령을 실행하십시오</p></item>
      <item><p><cmd>git push</cmd>를 실행하십시오</p></item>
    </steps>

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