• 버전 관리
• 업그레이드 권고사항
• 주요 버전 업그레이드
• 패치 릴리스
  • 오래된 릴리스로의 백포팅
  • 보안 릴리스
• 추가 정보

GitLab 릴리스 및 유지 정책

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

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

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

• 어떠한 시점에서도 현재 안정적인 릴리스에 대한 버그 수정만 하도록 백포팅합니다 - 아래의 패치 릴리스를 참조하세요.
• 보안 수정을 이전 두 달간의 릴리스 및 현재 안정적인 릴리스에 대한 백포팅을 합니다. 일부 경우에는(보안 릴리스 참조) 보안 취약점을 다루기 위해 패치 릴리스 프로세스나 정기적으로 매월 릴리스 프로세스를 사용하여 현재 안정적인 릴리스에 대한 업데이트를 제공하는 경우가 있습니다.

드문 경우에 릴리스 매니저들은 예외를 부여하고 더 이전의 릴리스에 대해 백포팅할 수 있습니다. 더 많은 정보는 이전 릴리스에 백포팅을 참조하세요.

버전 관리

GitLab은 릴리스에 대해 Semantic Versioning을 사용합니다: (주요).(마이너).(패치).

예를 들어, GitLab 버전 13.10.6에서:

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

버전 번호의 어떠한 부분도 여러 자릿수로 증가할 수 있습니다. 예를 들어 13.10.11.

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

업그레이드 권고사항

가장 안정적인 릴리스를 실행하여 GitLab 경험을 가장 안전하고 기능이 풍부하게 업그레이드할 수 있도록 최신 안정적 릴리스(https://about.gitlab.com/releases/categories/releases/)를 실행할 것을 권장합니다. 가장 최신의 안정적 릴리스를 실행할 수 있도록 하기 위해 우리는 업데이트 프로세스를 간단하고 안정적으로 유지하기 위해 노력하고 있습니다.

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

주요 버전 업그레이드

역호환성이 없는 변경 및 마이그레이션은 주요 버전에 보존됩니다. 업그레이드 가이드를 참조하세요.

패치 릴리스

패치 릴리스는 현재 안정적으로 릴리스된 버전에 대한 버그 수정만 포함합니다.

이 두 정책이 적용된 이유는 다음과 같습니다:

1. GitLab은 커뮤니티 및 엔터프라이즈 배포를 가지고 있어 소프트웨어의 테스트/릴리스를 위한 작업량이 두 배가 됩니다.
2. 둘 이상의 릴리스에 백포팅을 하는 것은 개발, 품질 보증 및 지원 비용을 상당히 증가시킵니다.
3. 병렬 버전을 지원하는 것은 시간이 지남에 따라 복잡성이 증가하고 모든 사용자에 대해 업그레이드 도전을 만드는 점에서 증가합니다. GitLab은 증분적 업그레이드가 가능하도록 보장하는 전담 팀을 보유하고 있습니다.
4. GitLab 응용프로그램에서 생성되는 변경 사항의 수가 많으며, 이는 낡은 출시에 대한 백포팅 복잡성에 기여합니다. 몇 가지 경우에는 백포팅이 새로운 변경 사항이 통과하는 리뷰 프로세스를 거쳐야 합니다.
5. 이전 릴리스에서 테스트가 통과하는 것을 보장하는 것은 몇 가지 경우에 대해 상당한 도전과 시간이 많이 소요됩니다.

패치 릴리스에 새로운 기능을 포함하는 것은 불가능합니다. 왜냐하면 그렇게 되면 Semantic Versioning을 어기게 되기 때문입니다. Semantic Versioning을 어기면 다음과 같은 사용자들에게 다음과 같은 결과를 초래합니다:

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의 더 많은 월간 릴리스에 대한 보안 수정을 백포팅할 수 있는 선례가 있습니다. 이 결정은 사례별로 이루어집니다.

특정 경우에는 취약점을 패치 릴리스 프로세스나 정기적인 월간 릴리스 프로세스로 처리하기로 선택할 수도 있습니다. 즉, 현재의 안정적인 릴리스만 업데이트하고 백포팅을 하지 않는 것입니다. 이 결정에 영향을 미치는 요인으로는 공격 가능성이 매우 낮거나 영향이 적을 때, 수정 복잡성 및 안정성 위험이 있습니다. 우리는 항상 높고 심각한 보안 문제에는 보안 릴리스로 대응하겠습니다.

추가 정보

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

• 릴리스 문서(https://gitlab.com/gitlab-org/release/docs)에 대한 설명
• 폐기 지침
• 책임 있는 공개 정책