GitLab 릴리스 및 유지보수 정책

배송 그룹(Delivery Group)은 유지 정책의 소유자로서 요청된 업데이트를 승인해야 합니다. 이는 우리의 DRI 모델을 따르며, 고객들에게 예측 가능성을 보장하기 위한 조치입니다.

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

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

  • 오직 현재 안정화된 릴리스에 대한 버그 수정을 백포트합니다. 자세한 사항은 아래의 패치 릴리스를 참조하세요.
  • 이전 2개월 릴리스와 현재 안정화된 릴리스에 대한 보안 수정을 백포트합니다. 특정 상황에서는(패치 릴리스에 기술되어 있음) 보안 취약점에 대해 현재 안정화된 릴리스에만 대응하거나 월간 릴리스 프로세스에서 백포트하지 않을 수 있습니다.

드물게, 릴리스 매니저는 최신 2개월 이상으로 백포트할 수 있는 예외를 만들 수 있습니다. 자세한 내용은 이전 릴리스로의 백포팅을 참조하세요.

버전 관리

GitLab은 릴리스에 시맨틱 버전을 사용합니다: (주요).(마이너).(패치).

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

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

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

다음 표는 버전 유형과 그들의 릴리스 주기를 설명합니다:

버전 유형 설명 주기
주요 중요한 변경 사항이나 공개 API에 하위 호환되지 않는 변경 사항이 소개되었을 때. 매년. 다음 주요 릴리스는 2025년 5월 15일에 예정된 GitLab 18.0입니다. GitLab은 기본적으로 매년 5월에 주요 릴리스를 예정하고 있습니다.
마이너 공개 API에 새로운 하위 호환적 기능이 소개되었을 때, 마이너 기능이 소개되었을 때, 또는 일련의 작은 기능이 지원되었을 때. 매월, 매월 세 번째 목요일에 예정됩니다.
패치 잘못된 동작을 수정하는 하위 호환적 버그 수정을 위해. 패치 릴리스를 참조하세요. 2개월에 한 번, 각 월간 마이너 릴리스 앞주와 뒷주 수요일에 예정됩니다.

업그레이드 권장

가능한 모든 분들에게 최신 안정화 릴리스를 실행하도록 권장하여 GitLab 경험을 가장 안전하고 기능이 풍부하게 업그레이드하실 수 있도록 하고 있습니다. 최신 안정화 릴리스를 실행할 수 있도록 하기 위해, 업데이트 프로세스를 간단하고 신뢰할 수 있도록 유지하고 있습니다.

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

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

참고: 리눅스 패키지를 로컬로 다운로드하고 수동으로 설치하는 방법에 대한 지침을 제공합니다.

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

주요 버전 업그레이드

하위 호환되지 않는 변경 사항과 마이그레이션은 주요 버전에 보류되어 있습니다. 자세한 내용은 GitLab 업그레이드 계획 생성을 참조하세요.

패치 릴리스

패치 릴리스에는 현재 안정화된 GitLab 릴리스 버전의 버그 수정과 이전 두 개월 릴리스에 대한 보안 수정이 포함됩니다.

이러한 정책은 다음과 같은 이유로 시행됩니다:

  1. GitLab에는 Community 및 Enterprise 배포가 있어 소프트웨어 테스트/릴리스를 위한 작업량이 두 배로 늘어납니다.
  2. 이전 릴리스로의 백포팅은 높은 개발, 품질 보증 및 지원 비용이 발생합니다.
  3. 병렬 버전 지원은 증분 업그레이드를 억제하며 이로 인해 모든 사용자에게 복잡성이 증가하고 업그레이드에 도전을 겪을 수 있습니다. GitLab은 증분 업그레이드(및 설치)가 가능한 한 간단해지도록 전담 팀이 있습니다.
  4. GitLab 애플리케이션에서 만들어지는 변경 사항 수가 많아 이로 인해 이전 릴리스로의 백포팅이 복잡해집니다. 몇 가지 경우에서는 백포팅이 새로운 변경 사항의 리뷰 프로세스를 거치도록 되어 있습니다.
  5. 이전 릴리스에서의 테스트가 어려운 경우가 있어서 시간과 비용이 많이 듭니다.

패치 릴리스에 새로운 기능을 포함시키는 것은 시맨틱 버전을 깨뜨리게 되므로 불가능합니다. 이로 인해 내부 요구 사항(예: 조직 규정, 새로운 기능의 확인 등)을 준수해야 하는 사용자들에게 다음과 같은 결과가 발생합니다:

  1. 패치 버전에 피해를 입힌 버그 수정을 빠르게 활용할 수 없음.
  2. 패치 버전에 포함된 보안 수정을 빠르게 활용할 수 없음.
  3. 안정화된 GitLab 릴리스 뿐만 아니라 모든 패치 버전에 대해 광범위한 테스트 필요.

매우 심각한 보안 문제의 경우, 이전 GitLab 릴리스 버전에 대한 보안 수정을 백포트하는 선례가 있습니다. 이 결정은 경우마다 개별적으로 이루어집니다.

특정 사용자가 특정 기능이 공식 릴리스되기 전에 테스트해야 하는 요구사항이 있는 경우, 해당 기능을 포함하는 릴리스 후보(RC) 버전을 만들 수 있습니다. 이 것은 극히 드문 경우에만 필요하며, 릴리스/업무 이슈 트래커에서 고려 요청을 올려서 검토할 수 있습니다. 릴리스 후보에는 특정 기능을 격리시키는 것이 쉽지 않기 때문에 다른 기능과 변경 사항도 포함됩니다(위와 유사한 이유). 릴리스 후보는 GitLab.com에 배포되는 코드나 공개적으로 접근 가능한 코드와 같은 것입니다.

오래된 릴리스로의 백포트

보안 수정에는 일반적으로 1개 이상의 안정적인 릴리스로의 백포트가 예약되어 있습니다(패치 릴리스 참조). 그러나 경우에 따라 버그 수정을 하나 이상의 안정적인 릴리스로에 백포트해야 할 수도 있으며, 이는 버그의 심각성에 따라 다릅니다.

변경 사항을 백포트할지 여부는 현재 릴리스 매니저의 재량으로 결정되며, 모든 다음 사항을 기준으로 합니다.

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

위의 모든 사항이 충족되면 현재 안정적인 릴리스와 최근 2개의 월간 릴리스에 대해 백포트 릴리스를 생성할 수 있으며, 드물게 릴리스 매니저가 최근 2개의 월간 릴리스 이상으로의 백포트에 대한 예외를 부여할 수 있습니다. 예를 들어, 심각한 버그 수정이 포함된 13.0.0에서 발생한 13.2.1 릴리스를 출시한 경우, 새로운 13.0.x 및 13.1.x 패치 릴리스로 해당 수정을 백포트할 수 있습니다.

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

고려를 위해 1개 이상의 안정적인 릴리스로의 백포트 요청을 하려면 릴리스/태스크 이슈 추적기에서 이슈를 제기하십시오.

추가 정보

다음을 참고해보시기 바랍니다: