지원 중단#

• 기능에 대한 지원 종료 또는 기능 제거 전에 필요합니다.
• 기능 사용을 권장하지 않습니다.
• 개발이 Priority 1 / Severity 1 버그 수정으로 제한됩니다.
• 향후 주요 릴리스에서 제거됩니다.
• 지원 종료 또는 제거 날짜를 명시하는 지원 중단 공지 후 시작됩니다.
• 지원 종료 날짜 또는 제거 날짜가 지난 후 종료됩니다.

지원 종료#

• 제거 전 선택적 단계입니다.
• 기능 사용을 강력히 권장하지 않습니다.
• 지원이나 수정이 제공되지 않습니다.
• 내부적으로 더 이상 테스트하지 않습니다.
• 향후 주요 릴리스에서 제거됩니다.
• 지원 종료 날짜가 지난 후 시작됩니다.

지원 종료 기간을 발표하는 것은 특별한 상황에서만 사용해야 하며 일반적인 사용에는 권장되지 않습니다. 대부분의 기능은 지원 중단된 후 제거되어야 합니다.

제거#

• 기능 사용이 불가능합니다.
• 기능이 더 이상 지원되지 않습니다(지원 종료 기간이 이미 발표되지 않은 경우).
• 시맨틱 버전 관리 정책에 따라 주요 릴리스에서 발생합니다.
• 제거 날짜가 지난 후 시작됩니다.

Breaking change#

고객이 GitLab 워크플로가 중단되지 않도록 조치를 취해야 하는 경우 해당 변경 사항은 breaking change로 간주됩니다.

Breaking change는 다음과 같은 소스에서 발생할 수 있습니다:

• 의도적인 제품 변경
• 구성 업데이트
• 타사 지원 중단

기본적으로 breaking change 구현 계획이 리더십의 승인을 받지 않는 한 breaking change는 허용되지 않습니다.

타사 의존성#

이 섹션은 모든 이전 용어에 적용됩니다.

타사 의존성의 변경(지원 중단, 지원 종료, 제거 또는 breaking change)은 GitLab 자체의 기능 변경과 별도로 처리됩니다:

• 이러한 변경은 의존성 자체의 라이프사이클을 따르며 GitLab의 기능 프로세스 및 타임라인 요구 사항의 적용을 받지 않습니다.
• GitLab은 제품에 영향을 미치는 타사 의존성 변경에 대해 영향을 최소화하고 원활한 마이그레이션 경험을 제공하기 위해 노력합니다.
• 취약성 해결 SLA 내에서 심각한 취약성을 해결하는 데 필요한 경우 표준 지원 중단 프로세스를 따르지 않고 의존성에 대한 보안 업데이트가 적용될 수 있습니다. 자세한 내용은 GitLab 핸드북을 참조하세요.
• 의존성이 당사의 통제 또는 타임라인 외부에서 변경되는 경우, GitLab은 기능, 호환성 또는 보안을 유지하기 위해 일반적인 프로세스 및 타임라인 외부에서 소프트웨어에 변경 사항을 구현해야 할 수 있습니다.
• GitLab은 중요한 타사 의존성 변경 사항을 전달하기 위해 합리적인 노력을 합니다.
• GitLab은 GitLab 제품에서 직접 사용하지 않는 타사 의존성 기능의 변경에 대해 책임을 지지 않습니다.
• GitLab의 사용 패턴 이상으로 이러한 타사 의존성을 활용하는 고객은 자신의 위험을 감수하며 다음을 수행해야 합니다:
  • 타사의 릴리스 노트를 독립적으로 모니터링합니다.
  • 새 의존성 버전에 대해 사용자 정의 구현을 테스트합니다.
  • 타사 변경을 위한 자체 마이그레이션 전략을 계획합니다.