• 버전 관리
• 업그레이드 권장
• 주요 버전 업그레이드
• 패치 릴리스
  • 이전 릴리스로 백포팅
• 추가 정보

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.

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

업그레이드 권장

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

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

주요 버전 업그레이드

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

패치 릴리스

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

이러한 정책은 다음과 같은 이유로 마련되었습니다:

1. GitLab은 커뮤니티 및 엔터프라이즈 배포를 갖추고 있어 소프트웨어를 테스트/릴리스하기 위한 작업량이 두 배가 필요합니다.
2. 이전 릴리스에 백포팅하는 것은 고개 개발, 품질 보증 및 지원 비용을 초래합니다.
3. 병렬 버전을 지원하는 것이 점진적으로 업그레이드하기를 방해하며, 시간이 흐름에 따라 복잡성을 누적함으로써 모든 사용자에게 업그레이드 도전을 발생시킵니다. GitLab은 점진적 업그레이드(및 설치)가 가능하도록 최대한 노력하는 전담 팀을 보유하고 있습니다.
4. GitLab 애플리케이션에 생성된 변경 사항의 수가 많으며, 이는 이전 릴리스에 백포팅 복잡성에 기여합니다. 몇몇 경우에는 백포팅이 새 변경이 거치는 동일한 검토 프로세스를 거쳐야 할 수 있습니다.
5. 이전 릴리스에서 테스트를 통과하는 것은 몇몇 경우에 매우 어려운 과제이고, 따라서 매우 시간이 소요됩니다.

패치 릴리스에 새 기능을 포함하는 것은 의미론적 버전을 위반하기 때문에 불가능합니다. 의미론적 버전을 위반하는 것은 내부 요구 사항(예: 조직 규정, 새로운 기능 확인 등)을 준수해야 하는 사용자에 대한 다음과 같은 결과를 낳습니다:

1. 패치 버전에 포함된 버그 수정을 빠르게 활용하는 것이 불가능합니다.
2. 패치 버전에 포함된 보안 수정을 빠르게 활용하는 것이 불가능합니다.
3. 안정적인 GitLab 릴리스 및 모든 패치 버전에 대한 포괄적인 테스트 요구 사항.

매우 심각한 보안 문제의 경우, 사례에 따라 심지어 이전 GitLab 릴리스 버전에 대한 보안 수정을 백포팅하는 경향이 있습니다. 이러한 결정은 케이스별로 결정됩니다.

특정 사용자가 특정 기능을 공식적으로 릴리스되기 전에 테스트할 필요가 있을 경우, 해당 기능이 포함된 릴리스 후보(Release Candidate, RC) 버전을 만들 수 있습니다. 이는 극히 드물게 필요한 경우에 한하여 요청을 통해 고려될 수 있습니다. 이러한 이유로 인해 해당 기능을 쉽게 격리시키는 것이 불가능한 관계로 릴리스 후보에는 다른 기능 및 변경 사항이 포함됩니다. 릴리스 후보는 GitLab.com에 배포된 코드 또는 공개적으로 접근 가능한 코드와 동일합니다.

이전 릴리스로 백포팅

일반적으로 하나 이상의 안정 릴리스로 백포팅하는 것은 보안 수정을 위해 예약되어 있습니다. 그러나 특정 경우에는 버그 수정을 더 많은 안정 릴리스로 백포팅해야 할 수 있습니다. 이는 버그의 심각성에 따라 결정됩니다.

백포팅 변경 사항을 수행할지 여부 결정은 현재 릴리스 매니저들에 의해 모든 다음을 기반으로 합니다:

1. 추정된 심각도: 현재 심각도의 정의를 기반으로 사용자에게 최고의 영향을 미칠 수 있는 최고의 영향.
2. 추정된 우선 순위: 위의 추정된 심각도에 따른 모든 영향을 즉각적으로 받는 사용자에게 영향.
3. 잠재적인 데이터 손실 및/또는 보안 위반.
4. 한 개 이상의 전략적 계정에 영향을 미칠 수 있음이 사용자의 현재 안정 버전으로 업그레이드 불가능함.

만약 위의 모든 항목을 만족하는 경우, 백포팅 릴리스를 현재 안정 릴리스와 이전 두 달간의 릴리스에 대해 만들 수 있습니다. 흔히 발생하는 경우에는 릴리스 매니저가 예외를 허용하여 두 달 이전의 릴리스로 백포팅할 수 있습니다. 예를 들어, 13.0.0에 소개된 심각한 버그를 수정한 13.2.1을 릴리스하면 새로운 13.0.x 및 13.1.x 패치 릴리스로 백포팅할 수 있습니다.

심각도 3 및 낮은 요청은 자동으로 거부됩니다.

두 개 이상의 안정 릴리스로 백포팅을 요청하려면 백포팅 요청 이슈 트래커에서 문제를 제기하세요.

추가 정보

다음 내용도 읽어보시기 바랍니다:

• 릴리스 절차를 설명하는 릴리스 문서
• 사용 중단 가이드라인
• 책임 있는 공개 정책(Responsible Disclosure Policy)은 여기에서 확인하실 수 있습니다.