GitLab 릴리스 및 유지 정책

배달 그룹은 유지 정책을 소유하고 있으며 요청된 업데이트를 승인해야 합니다. 이는 DRI 모델에 따라 고객들에게 예측 가능성을 보장하기 위한 것입니다.

GitLab은 주요, 마이너, 패치, 보안 릴리스의 버전 네이밍 및 릴리스 속도를 규제하는 엄격한 정책을 가지고 있습니다. 새로운 릴리스는 GitLab 블로그에서 발표됩니다.

저희의 현재 정책은 다음과 같습니다:

  • 어떠한 시점에서도 현재 안정 버전에 대한 버그 수정만 포트합니다 - 패치 릴리스 참조.
  • 보안 수정 사항을 현재 안정 버전과 이전 두 달간의 릴리스에 대해 포트합니다. 특정 상황에서는 보안 취약점을 처리하기 위해 패치 릴리스 프로세스나 정기 월간 릴리스 프로세스(즉, 현재 안정 버전에 대한 업데이트만 제공)를 사용할 수 있습니다.

드물게, 릴리스 매니저는 예외를 만들어 이전 릴리스로 포트하는 경우가 있습니다. 자세한 내용은 이전 릴리스로의 포팅을 참조하세요.

버전 관리

GitLab은 릴리스에 의미론적 버전 관리를 사용합니다: (메이저).(마이너).(패치).

예를 들어, GitLab 버전 13.10.6의 경우:

  • 13은 주요 버전을 나타냅니다. 주요 릴리스는 13.0.0이지만, 보통 13.0으로 언급됩니다.
  • 10은 마이너 버전을 나타냅니다. 마이너 릴리스는 13.10.0이지만, 보통 13.10으로 언급됩니다.
  • 6은 패치 번호를 나타냅니다.

버전 번호의 어떤 부분이든 여러 자릿수로 증가할 수 있습니다. 예를 들어, 13.10.11입니다.

다음 표는 버전 유형 및 릴리스 주기를 설명합니다:

버전 유형 설명 주기
주요 중대한 변경 사항 또는 공개 API에 호환되지 않는 변경이 도입된 경우. 매년 한 번. 다음 주요 릴리스는 2024년 5월 16일에 예정된 GitLab 17.0입니다. GitLab은 기본적으로 매년 5월에 주요 릴리스를 예정합니다.
마이너 공개 API에 새로운 호환 기능이 도입되거나, 하위 호환 기능이 도입되거나, 일련의 작은 기능이 출시된 경우. 매월.
패치 부적절한 동작을 수정하는 호환되는 버그 수정을 위한 것. 패치 릴리스 참조. 필요 시.

업그레이드 권장

가장 안정적인 릴리스에서 업그레이드하여 가장 안전하고 기능이 풍부한 GitLab 경험을 할 수 있도록 모든 사람들에게 권장합니다. 가장 최근 안정 버전을 실행할 수 있도록하여 업데이트 프로세스를 간단하고 신뢰할 수 있게 유지하고자 노력하고 있습니다.

월간 릴리스 주기를 따라갈 수 없는 경우 고려해야 할 몇 가지 사항이 있습니다. 버전 간 안전하게 업그레이드하기 위해 업그레이드 경로 안내서를 따르세요.

참고: 리눅스 패키지의 버전별 변경 사항은 리눅스 패키지 문서에서 확인할 수 있습니다.

참고: 로컬로 Linux 패키지를 다운로드하고 수동으로 설치하는 방법에 대한 지침이 제공됩니다.

참고: Linux 패키지 번들화된 PostgreSQL을 업그레이드하는 단계별 안내서가 별도로 문서화되어 있습니다.

주요 버전 업그레이드

하위 호환되지 않는 변경 사항 및 마이그레이션은 주요 버전을 위해 예약됩니다. 업그레이드 안내서를 참조하세요.

패치 릴리스

패치 릴리스는 현재 안정 버전의 버그 수정만을 포함합니다.

이러한 두 가지 정책이 존재하는 이유는 다음과 같습니다:

  1. GitLab은 Community 및 Enterprise 배포를 가지고 있어 소프트웨어를 테스트/릴리스하는 데 필요한 작업량을 두 배로 만듭니다.
  2. 하나 이상의 릴리스로의 포팅은 높은 개발, 품질 보증 및 지원 비용을 초래합니다.
  3. 병렬 버전을 지원하는 것은 시간이 지남에 따라 복잡성이 증가하고 모든 사용자에게 업그레이드 도전 과제를 만들어내므로, 점진적 업그레이드를 방해합니다. GitLab은 점진적 업그레이드(및 설치)를 가능한 간단하게 하는 데 전념한 팀을 보유하고 있습니다.
  4. GitLab 애플리케이션에 생성된 변경 내용의 수가 많으며, 이는 이전 릴리스로의 포팅 복잡성에 기여합니다. 몇 가지 경우에서, 포팅은 새로운 변경 사항이 거치는 리뷰 프로세스와 동일한 프로세스를 거쳐야 합니다.
  5. 테스트가 이전 릴리스에서 통과되도록 보장하는 것은 경우에 따라 상당한 도전 과제입니다. 때때로 이는 매우 시간 소비가 많이 필요합니다.

패치 릴리스에 새로운 기능을 추가하는 것은 의미론적 버전 관리를 위반하기 때문에 불가능합니다. 의미론적 버전 관리 위반이 사용자에게 다음과 같은 결과를 초래합니다.

  1. 패치 버전에 포함된 버그 수정을 신속하게 활용하기 어렵게 됨.
  2. 패치 버전에 포함된 보안 수정을 신속하게 활용하기 어렵게 됨.
  3. 안정적인 GitLab 릴리스만이 아니라 모든 패치 버전에 대해 방대한 테스트가 요구됨.

전략적 사용자가 공식적으로 릴리스되기 전에 기능을 테스트하는 요구사항이 있는 경우, 특정 기능을 포함하는 RC(릴리스 후보) 버전을 제공할 수 있습니다. 이는 극단적인 경우에만 필요하고 릴리스/작업 이슈 트래커에 문제를 제기하여 고려받을 수 있습니다. 특정 기능을 격리하는 것이 쉽지 않기 때문에, RC에는 다른 기능 및 변경 사항이 포함되어 있습니다(위에서 언급된 이와 유사한 이유로). 릴리스 후보는 GitLab.com에 배포되거나 공개적으로 접근 가능한 다른 코드와 다를 바가 없습니다.

이전 릴리스로의 백포트

한 개 이상의 안정적 릴리스로의 백포팅은 보통 보안 릴리스를 위해 예약됩니다. 그러나 심각한 버그의 심각성에 따라 경우에 따라 버그 수정을 한 개 이상의 안정적 릴리스로 백포트해야 할 수도 있습니다.

변경 사항을 백포팅할지 여부는 현재 릴리스 매니저들의 재량에 따라 결정되며, 이를 위해서 아래의 모든 사항이 고려됩니다:

  1. 추정된 심각성에 대한 예상: 현재 심각성 정의에 따른 사용자에게 최대의 영향.
  2. 추정된 우선 순위에 대한 예상: 상기 추정된 심각성에 따른 모든 영향 받는 사용자에게 즉각적인 영향.
  3. 데이터 손실 및/또는 보안 위반 가능성.
  4. 현재 안정적인 버전으로의 업그레이드가 사용자에 의해 증명된 가능성으로 인해 하나 이상의 전략적 계정에 영향을 줄 가능성.

위의 모든 사항이 충족되면, 백포팅 릴리스는 현재 안정적인 릴리스 및 이전 두 달간의 릴리스를 위해 생성될 수 있습니다. 드물게 릴리스 매니저는 두 개의 이전 달간 릴리스보다 더 많은 릴리스로의 백포트에 대한 예외를 부여할 수 있습니다. 예를 들어, 심각한 버그 수정을 포함한 13.0.0에서 발표한 13.2.1이 있는 경우, 해당 수정을 새로운 13.0.x 및 13.1.x 패치 릴리스로 백포팅할 수 있습니다.

심각성 3 이하의 요청은 자동으로 거부됩니다.

한 개 이상의 안정적 릴리스로의 백포팅을 요청하려면, release/tasks 이슈 트래커에서 이슈를 제기하십시오.

보안 릴리스

보안 릴리스는 현재 안정적인 릴리스에 추가하여 이전 두 달간의 릴리스에 대한 보안 수정과 패치를 포함하는 특별한 유형의 패치 릴리스입니다.

매우 심각한 보안 문제에 대해, GitLab의 더 많은 월간 릴리스로 보안 수정을 백포팅하는 선례가 있습니다. 이 결정은 사례별로 이루어집니다.

일부 상황에서는 패치 릴리스 프로세스나 정기적인 월간 릴리스 프로세스를 사용하여 취약성을 다루거나, 즉, 현재 안정적인 릴리스만을 업데이트하고 백포트를 수행하지 않을 수 있습니다. 이 결정에 영향을 미치는 요소로는, 공격 가능성 가능성이 매우 낮음, 영향이 낮음, 고치기가 복잡하며 안정성에 대한 위험이 있습니다. 높은 및 심각한 보안 문제는 항상 보안 릴리스로 처리할 것입니다.

추가 정보

다음을 읽어보시기를 권장합니다: