제품 가용성 상세정보

제품 가용성 세부정보는 특징에 관한 정보를 제공하며 주제 제목 아래에 표시됩니다.

가용성 정보에는 등급, 제공 여부, 상태 및 이력이 포함됩니다.

가용성 세부정보의 Markdown는 다음과 같아야 합니다.

# 주제 제목

DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
**Status:** Experiment

> - [GitLab 16.3에서 도입됨](https://link-to-issue)
> - GitLab 16.4에서 업데이트됨.

사용 가능한 옵션

등급, 제공 여부, 상태 및 버전 이력에 대해 다음 텍스트를 사용하세요.

제공 여부

제공 여부에 대해 다음 단어들의 조합을 사용하되, 이 순서대로 쉼표로 구분하세요:

  • GitLab.com
  • Self-managed
  • GitLab Dedicated

예를 들어:

  • GitLab.com
  • GitLab.com, Self-managed
  • Self-managed
  • Self-managed, GitLab Dedicated

등급

등급은 다음 중 하나를 선택하세요:

  • Free, Premium, Ultimate
  • Premium, Ultimate
  • Ultimate

GitLab Duo Pro 또는 Enterprise 추가 기능

추가 기능에 대해 “with”와 추가 기능을 사용하여 문서화합니다. 예: with GitLab Duo Pro.

2024년 8월 기준으로, Code Suggestions를 제외한 모든 GitLab Duo 기능에는 앞으로의 등급 문장이 포함됩니다. 추가 기능이 적용되는 경우 다음과 같은 문장을 사용하세요:

**Tier:** 임시로 Premium 또는 Ultimate. 2024년 10월 17일에, GitLab Duo Pro와 함께 Premium 또는 GitLab Duo Pro 또는 Enterprise와 함께 Ultimate [GitLab Duo Pro 또는 Enterprise](https://about.gitlab.com/gitlab-duo/#pricing).
**Tier:** 임시로 Ultimate. 2024년 10월 17일에, [GitLab Duo Pro 또는 Enterprise와 함께 Ultimate](https://about.gitlab.com/gitlab-duo/#pricing).
**Tier:** 임시로 Ultimate. 2024년 10월 17일에, [GitLab Duo Enterprise와 함께 Ultimate](https://about.gitlab.com/gitlab-duo/#pricing).

각 제공 여부(GitLab.com, Self-managed)에 대해 추가 기능이 적용되는 경우, 다음 형식을 사용하세요:

**Tier: GitLab.com 및 Self-managed:** 임시로 Premium 또는 Ultimate. 2024년 10월 17일에, GitLab Duo Pro와 함께 Premium 또는 GitLab Duo Pro 또는 Enterprise [GitLab Duo Pro 또는 Enterprise](https://about.gitlab.com/gitlab-duo/#pricing). **GitLab Dedicated:** GitLab Duo Pro 또는 Enterprise.

참고: GitLab Dedicated는 항상 Ultimate 구독에 포함됩니다.

상태

상태는 다음 중 하나를 선택하세요:

  • Beta
  • Experiment

일반적으로 사용 가능한 기능에는 상태를 포함하지 마세요.

이력

버전 이력에는 다음 순서대로 이 단어들이 포함되어야 합니다. 대문자/소문자 구분은 중요하지 않습니다.(GitLab를 제외하고):

  • 도입됨, 추가됨, 활성화됨, 사용 불가 설정, 변경됨, 이동됨, 권장됨, 제거됨, 또는 이름이 변경됨.
  • in 또는 to
  • GitLab (또는 외부 프로젝트인 경우 해당 프로젝트의 이름)

문서 사이트에서는 Ruby code을 사용하여 이러한 단어를 기반으로 버전 이력을 렌더링합니다.

추가로:

  • 출력이 올바르게 생성되는지 확인하세요.
  • 버전 이력이 > -로 시작하는지 확인하세요.
  • 가능하다면 관련 이슈, 병합 요청 또는 이슈에 대한 링크를 포함하세요.
  • 가격 페이지에 링크하지 마세요. 구독 등급을 포함하지 마세요.

업데이트된 기능

변경되거나 업데이트된 기능에 대해 새로운 목록 항목을 추가하세요. 문장은 기능 이름이나 -ing로 시작하세요.

예를 들어:

> - [GitLab 13.1에서 도입됨](https://issue-link)
> - 이슈 보드에서 이슈 생성 [GitLab 14.1에서 도입됨](https://issue-link).

또는:

> - [GitLab 13.1에서 도입됨](https://issue-link)
> - 만료되는 토큰에 대한 알림 [GitLab 14.3에서 도입됨](https://issue-link).

구독 등급 변경

다른 구독 등급으로 이동하는 기능에 대해 이동됨을 사용하세요:

> - [GitLab Ultimate에서 11.8로 이동됨](https://issue-link)
> - [GitLab Premium에서 GitLab Free로 이동됨](https://issue-link)

기능 상태 변경

실험 상태에서 베타 상태로 변경된 경우, 변경됨을 사용하세요:

> - [GitLab 15.7에서 [실험 상태로 도입됨](../../policy/experiment-beta-support.md)
> - GitLab 16.0에서 베타 상태로 변경됨.

일반적으로 사용 가능한 상태로 변경된 경우:

> - [GitLab 16.10에서 일반적으로 사용 가능해짐](https://issue-link)

프로그램의 일환으로 사용 가능한 기능

프로그램의 일환으로 사용 가능한 기능인 경우, 새로운 목록 항목을 추가하고 프로그램에 대한 링크를 포함하세요.

> - [GitLab 15.1에서 도입됨](https://issue-link)
> - 병합된 결과 파이프라인은 [GitLab 16.7의 [등록 기능 프로그램](https://page-link)에 추가됨](https://issue-link).

기능 플래그 뒤에 숨겨진 기능

기능 플래그 뒤에 도입된 기능에 대한 세부 정보를 추가하세요. 자세한 정보는 기능 플래그 뒤에 배포된 기능 문서를 참조하세요.

버전 제거

지원되지 않는 버전을 가리키는 이력 항목과 내부 텍스트를 제거하세요.

GitLab은 현재 주요 버전 및 이전 주요 버전 2개를 지원합니다. 예를 들어, 16.0이 현재 주요 버전인 경우, GitLab 16.0, 15.0 및 14.0의 모든 주요 및 마이너 릴리스가 지원됩니다.

현재 지원되는 버전 목록은 버전 지원을 참조하세요.

기능 플래그 뒤에 배포된 기능에 관한 정보는 지원되지 않는 버전에서 일어난 모든 이벤트에 대해서만 제거하세요. 플래그가 제거되지 않았다면, 도입된 날짜를 알아야 합니다.

Timing version removals

새로운 주요 버전이 곧 출시될 때, 마지막으로 지원되지 않는 버전을 언급한 병합 요청을 만듭니다. 새 주요 릴리스의 마일스톤에서만 병합하세요.

예를 들어, GitLab 17.0이 다음 주요 릴리스라면:

  • 지원되는 버전은 16, 15, 14입니다.
  • GitLab 17.0이 출시되면, GitLab 14는 더 이상 지원되지 않습니다.

GitLab 14 언급을 제거하는 병합 요청을 만드세요. 다만, 16.11이 출시된 후 17.0 마일스톤에서만 병합하세요.

추가 세부 정보를 추가해야 하는 시기

다음에 세부 정보를 할당하세요:

  • doc/development/*doc/solutions/* 하위 페이지를 제외한 대부분의 H1 주제 제목.
  • H1 제목과 다른 사용 가능성 세부 정보가 있는 기능의 주제 제목.

H1 사용 가능성 세부 정보는 페이지의 기능에 대한 가장 넓은 사용 가능성에 적용되는 세부 정보여야 합니다. 예를 들어:

  • 일부 섹션이 프리미엄 및 얼티메이트에 적용되고, 다른 섹션이 얼티메이트에만 적용되는 경우, Tier:프리미엄, 얼티메이트여야 합니다.
  • 일부 섹션이 모든 인스턴스에 적용되고, 다른 섹션이 자체 관리 전용인 경우, Offering:GitLab.com, Self-managed, GitLab Dedicated여야 합니다.
  • 일부 섹션이 베타 상태이고, 다른 섹션이 실험이면, H1 Status:베타여야 합니다. 일부 섹션이 베타 상태이고, 다른 섹션이 일반적으로 사용 가능한 경우 H1에는 Status:가 없어야 합니다.

사용 가능성 세부 정보를 추가해서는 안 되는 경우

다음 페이지에 사용 가능성 세부 정보를 할당하지 마세요:

  • 튜토리얼.
  • 다른 티어의 기능을 비교하는 페이지입니다.
  • /development 폴더의 페이지입니다. 이러한 페이지는 자동으로 Contribute 뱃지가 지정됩니다.
  • /solutions 폴더의 페이지입니다. 이러한 페이지는 자동으로 Solutions 뱃지가 지정됩니다.

또한, 어떤 기능이 하나의 명백한 구독 티어나 오퍼링을 갖지 않는 경우에도 그 세부 정보를 할당하지 마세요. 예를 들어, 특정 기능이 GitLab.com에서 한 티어에 적용되고, 자체 관리에는 다른 사용 가능성이 적용되는 경우입니다.

이 경우, 다음을 수행하세요.

  • 사용 가능성 세부 정보를 설명하는 NOTE 알림 상자를 사용합니다.
  • 이 정보가 더 의미가 있는 다른 주제 제목 하에 사용 가능성 세부 정보를 추가하세요.
  • H1 하에 사용 가능성 세부 정보를 추가하지 마세요.

하위 제목의 티어, 오퍼링 또는 상태 중복

하위 제목이 부모 주제와 동일한 티어, 오퍼링 또는 상태를 갖는 경우에는 해당 정보를 하위 제목의 뱃지에 반복해서 쓸 필요가 없습니다.

예를 들어, H1 제목이:

# 나의 제목

DETAILS:
**오퍼링:** GitLab.com
**티어:** 프리미엄, 얼티메이트

동일한 오퍼링이지만 다른 티어에 적용되는 하위 수준 헤딩은:

## 나의 제목

DETAILS:
**티어:** 얼티메이트

인라인 사용 가능성 세부 정보

일반적으로, 다른 텍스트에 인라인으로 사용 가능성 세부 정보를 추가하지 않아야 합니다. 기능의 단일 정보 원천은 기능이 설명된 주제여야합니다.

인라인으로 사용 가능성 세부 정보를 언급해야 할 경우, 일반 텍스트로 작성하세요. 예를 들어, API 주제의 경우:

이슈를 할당하는 사용자의 ID. 얼티메이트 전용.

더 많은 예제는 REST API 스타일 가이드를 참조하세요.

인라인 기록 텍스트

기존 주제에 내용을 추가하는 경우, 기존 텍스트와 인라인으로 역사적인 정보를 추가하세요. 가능하다면, 관련된 이슈, 병합 요청 또는 에픽에 대한 링크를 포함하세요. 예를 들어:

투표 전략은 [GitLab 13.4 이후](https://issue-link)에서 주요 및 보조 투표자가 동의해야 합니다.

사용 가능성 세부 정보에 대한 관리자 설명서

인스턴스 관리자 전용인 주제는 Self-managed 티어여야 합니다. 인스턴스 관리자 문서에는 종종 다음을 언급합니다:

  • gitlab.rb 또는gitlab.yml 파일을 변경하기.
  • 레일스 콘솔에 액세스하거나 Rake 작업을 실행하기.
  • Admin 영역에서 작업하기.

이러한 페이지는 또한 작업을 인스턴스 관리자만 수행할 수 있는 경우에도 언급해야 합니다.