GitLab 릴리스 및 유지 관리 정책

Delivery Group는 유지 관리 정책의 소유자이며 요청된 업데이트를 승인해야 합니다. 이는 고객에게 예측 가능성을 보장하기 위해 마련된 DRI 모델을 따릅니다.

GitLab은 버전 명명 및 주요, 부, 패치 릴리스의 릴리스 속도에 대한 엄격한 정책을 갖고 있습니다. 새로운 릴리스는 GitLab 블로그에서 발표됩니다.

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

  • 현재 안정 릴리스에 대해서만 버그 수정을 백포트합니다 - 아래 패치 릴리스를 참조하세요.
  • 현재 안정 릴리스 외에도 지난 두 개의 월간 릴리스에 보안 수정을 백포트합니다. 일부 상황에서는 (아래 패치 릴리스에서 설명됨) 보안 취약점을 현재 안정 릴리스 또는 정기 월간 릴리스 프로세스에서만 해결할 수 있으며, 백포트는 없습니다.

드물게 릴리스 관리자는 예외를 두고 마지막 두 개의 월간 릴리스를 초과하여 백포트를 진행할 수 있습니다. 더 많은 정보는 이전 릴리스에 대한 백포트를 참조하세요.

버전 관리

GitLab은 릴리스에 Semantic Versioning을 사용합니다: (Major).(Minor).(Patch).

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

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

버전 번호의 모든 부분은 여러 자리 수로 증가할 수 있습니다. 예: 13.10.11.

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

버전 유형 설명 주기
Major 중요한 변경, 또는 공용 API에 대한 하위 호환성 없는 변경이 도입될 때. 매년. 다음 주요 릴리스는 2025년 5월 15일로 예정되어 있는 GitLab 18.0입니다. GitLab은 매년 5월에 주요 릴리스를 일정적으로 배포합니다.
Minor 공용 API에 새로운 하위 호환 기능이 도입되거나, 부가적인 기능이 도입되거나, 소규모 기능 세트를 단계적으로 배포할 때. 매월, 매月 셋째 목요일로 예정되어 있습니다.
Patch 잘못된 동작 수정의 하위 호환성 있는 버그 수정. 패치 릴리스를 참조하세요. 격월, 매월 부 릴리스 전 주 수요일과 그 주 수요일에 정해져 있습니다.

업그레이드 추천

모든 사용자에게 가장 최신 안정 릴리스를 실행하도록 권장합니다. 이를 통해 가장 안전하고 기능이 풍부한 GitLab 경험을 보장할 수 있습니다.

가장 최근의 안정 릴리스를 실행할 수 있도록 업데이트 프로세스를 간단하고 신뢰할 수 있도록 열심히 작업하고 있습니다.

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

note
Linux 패키지에서 버전별 변경 사항은 Linux 패키지 문서에서 확인할 수 있습니다.
note
Linux 패키지를 로컬에서 다운로드하고 수동으로 설치하는 방법에 대한 지침이 제공됩니다.

주요 버전 업그레이드

하위 호환성이 없는 변경 사항 및 마이그레이션은 주요 버전에 예약되어 있습니다. 더 많은 정보는 GitLab 업그레이드 계획 수립하기를 참조하세요.

패치 릴리스

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

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

  1. GitLab은 커뮤니티 및 기업 배포가 있어 소프트웨어를 테스트/출시하는데 필요한 작업량이 두 배로 증가합니다.

  2. 이전 릴리스에 대한 백포팅은 높은 개발, 품질 보증 및 지원 비용을 초래합니다.

  3. 병행 버전 지원은 점진적인 업그레이드를 저해하며 시간이 지남에 따라 복잡성을 축적하고 모든 사용자에게 업그레이드 문제를 발생시킵니다. GitLab은 점진적인 업그레이드(및 설치)가 가능한 한 간단하도록 보장하는 전담 팀이 있습니다.

  4. GitLab 애플리케이션에서 생성된 변경 사항의 수가 많아 이전 릴리스에 대한 백포팅 복잡성을 초래합니다. 여러 경우에 백포팅은 새로운 변경 사항과 같은 검토 프로세스를 거쳐야 합니다.

  5. 이전 릴리스에서 테스트가 통과하도록 보장하는 것은 경우에 따라 상당한 도전 과제가 되며, 따라서 매우 시간이 소요됩니다.

패치 릴리스에 새로운 기능을 포함하는 것은 시맨틱 버전 관리를 깨뜨리므로 불가능합니다.

시맨틱 버전 관리를 깨뜨리는 것은 다양한 내부 요구 사항(예: 조직 준수, 새로운 기능 검증 등)에 따라야 하는 사용자에게 다음과 같은 결과를 초래합니다:

  1. 패치 버전에 포함된 버그 수정을 활용하기 위해 신속하게 업그레이드할 수 없음.

  2. 패치 버전에 포함된 보안 수정을 활용하기 위해 신속하게 업그레이드할 수 없음.

  3. 안정적인 GitLab 릴리스뿐만 아니라 모든 패치 버전에 대한 광범위한 테스트 요구 사항.

매우 심각한 보안 문제의 경우, 더 이전 GitLab 릴리스 버전에도 보안 수정을 백포팅하는 선례가 있습니다.

이 결정은 경우에 따라 이루어집니다.

일부 경우에는, 우리는 활성 및 현재 안정 릴리스만 업데이트하여 백포팅 없이 정기 월간 릴리스 프로세스를 사용해 취약점을 해결하기로 선택할 수 있습니다. 이 결정을 좌우하는 요소에는

위험한 악용 가능성의 매우 낮은 확률, 취약점의 낮은 영향, 보안 수정의 복잡성, 안정성에 대한 최종 위험이 포함됩니다. 우리는 항상 패치 릴스를 통해 높은 및 치명적인 보안 문제를 해결합니다.

전략적 사용자에게 기능이 공식적으로 릴리스되기 전에 테스트할 요구가 있는 경우, 특정 기능이 포함된 릴리스를 준수(RC) 버전을 만들 것을 제안할 수 있습니다. 이것은 극단적인 경우에만 필요하며 release/tasks 이슈 트래커에 문제를 제기하여 요청할 수 있습니다.

릴리스 후보는 특정 기능을 쉽게 분리할 수 없으므로 다른 기능 및 변경 사항을 포함한다는 점에 유의하는 것이 중요합니다(위에서 언급된 유사한 이유). 릴리스 후보는 GitLab.com에 배포되거나 공개적으로 접근 가능한 모든 코드와 다르지 않습니다.

이전 릴리스에 대한 백포팅

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

변경 사항의 백포팅 여부 결정은 모든 다음 사항을 기준으로 현재 릴리스 관리자의 재량에 따라 이루어집니다:

  1. 버그의 예상 심각성: 현재 심각성 정의에 따라 사용자에게 가장 높은 영향을 미치는 경우.

  2. 버그의 예상 우선순위: 위의 예상 심각성에 따라 모든 영향을 받는 사용자에게 즉각적인 영향을 미치는 경우.

  3. 데이터 손실 및/또는 보안 위반의 가능성.

  4. 사용자가 현재 안정 버전으로 업그레이드할 수 없다는 입증된 문제로 인해 하나 이상의 전략적 계정에 영향을 미칠 수 있습니다.

위의 모든 조건이 충족되면, 현재 안정 릴리스 및 두 개의 이전 월간 릴리스를 위한 백포팅 릴리스를 만들 수 있습니다. 드문 경우에는 릴리스 관리자가 두 개 이상의 이전 월간 릴리스에 대한 백포팅 예외를 허용할 수 있습니다. 예를 들어, 13.2.1을 심각한 버그 수정으로 출시하면, 13.0.x 및 13.1.x 패치 릴리스에 수정을 백포팅할 수 있습니다.

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

하나 이상의 안정 릴리스에 대한 백포팅을 요청하려면, release/tasks 이슈 트래커에 문제를 제기하세요.

추가 정보

다음 문서를 읽어보는 것도 좋습니다: