제품 가용성 세부정보

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

가용성 세부정보에는 티어, 오퍼링, 상태 및 기록이 포함됩니다.

가용성 세부정보의 Markdown 형식은 다음과 같아야 합니다:

# 주제 제목

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

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

사용 가능한 옵션

다음 텍스트를 티어, 오퍼링, 상태 및 버전 기록에 사용하세요.

Offering

오퍼링의 경우, 다음 단어 중 조합을 사용하여 이 순서로, 쉼표로 구분합니다:

  • GitLab.com
  • Self-managed
  • GitLab Dedicated

예시:

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

Tier

티어는 다음 중 하나를 선택합니다:

  • 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일, Premium with GitLab Duo Pro 또는 Ultimate with [GitLab Duo Pro or Enterprise](https://about.gitlab.com/gitlab-duo/#pricing).
**Tier:** 한정된 시간 동안, Ultimate. 2024년 10월 17일, Ultimate with [GitLab Duo Pro or Enterprise](https://about.gitlab.com/gitlab-duo/#pricing).
**Tier:** 한정된 시간 동안, Ultimate. 2024년 10월 17일, Ultimate with [GitLab Duo Enterprise](https://about.gitlab.com/gitlab-duo/#pricing).

각 오퍼링(GitLab.com, Dedicated, self-managed)에 대해 어떤 애드온이 적용되는지 구분해야 할 수 있습니다. 구분해야 할 경우, 다음 형식을 사용하세요:

**Tier: GitLab.com 및 Self-managed:** 한정된 시간 동안, Premium 또는 Ultimate. 2024년 10월 17일, Premium with GitLab Duo Pro 또는 Ultimate with [GitLab Duo Pro or Enterprise](https://about.gitlab.com/gitlab-duo/#pricing). **GitLab Dedicated:** GitLab Duo Pro 또는 Enterprise.

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

Status

상태는 다음 중 하나를 선택합니다:

  • Beta
  • Experiment

일반적으로 사용 가능한 기능은 상태가 없어야 합니다.

History

버전 기록을 위해 다음 단어를 순서대로 포함합니다. 대문자 사용은 상관없습니다(단, GitLab을 제외하고).

  • introduced, added, enabled, deprecated, changed, moved, recommended, removed, 또는 renamed
  • in 또는 to
  • GitLab (또는 외부 프로젝트의 경우 프로젝트 이름)

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

추가로:

  • 출력이 제대로 생성되는지 확인하세요.
  • 버전 기록은 > -로 시작해야 합니다.
  • 가능하면 관련 문제, 머지 요청 또는 에픽에 대한 링크를 포함하세요.
  • 가격 페이지로 링크하지 마세요. 구독 티어를 포함하지 마세요.

업데이트된 기능

변경되거나 업데이트된 기능의 경우 새 목록 항목을 추가하세요.

기능 이름이나 동명사를 문장의 시작으로 사용하세요.

예를 들어:

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

또는:

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

이동한 구독 계층

다른 구독 계층으로 이동된 기능의 경우 moved를 사용하세요:

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

변경된 기능 상태

기능 상태가 실험에서 베타로 변경된 경우 changed를 사용하세요:

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

일반적으로 사용 가능으로의 변경의 경우:

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

프로그램의 일환으로 제공되는 기능

프로그램의 일환으로 사용자에게 제공되는 기능의 경우 새 목록 항목을 추가하고 프로그램에 링크를 걸어주세요.

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

기능 플래그 뒤에 있는 기능

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

제거된 버전

지원되지 않는 버전을 참조하는 기록 항목 및 인라인 텍스트를 제거하세요.

GitLab은 현재 주요 버전과 두 개의 이전 주요 버전을 지원합니다.

예를 들어, 16.0이 현재 주요 버전이라면 GitLab 16.0, 15.0 및 14.0의 모든 주요 및 부 버전이 지원됩니다.

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

지원되지 않는 버전에서 모든 이벤트가 발생한 경우에만 기능 플래그 뒤에 있는 기능에 대한 정보를 제거하세요.

플래그가 제거되지 않았다면 독자는 그것이 언제 도입되었는지 알 수 있어야 합니다.

버전 제거 일정

새로운 주요 버전이 출시될 예정일 때, 마지막 지원되지 않는 버전에 대한 언급을 제거하기 위한 병합 요청을 생성하세요.

새로운 주요 릴리스의 마일스톤 동안에만 병합하세요.

예를 들어, GitLab 17.0이 다음 주요 출시일 경우:

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

GitLab 14에 대한 언급을 제거하기 위한 병합 요청을 생성하세요. 그러나 16.11이 출시된 후에만 17.0 마일스톤 동안에만 병합하세요.

가용성 세부정보를 추가하는 시기

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

  • 대부분의 H1 주제 제목, doc/development/* 및 doc/solutions/* 아래의 페이지를 제외합니다.
  • H1 제목과 가용성 세부정보가 다른 기능에 대한 주제 제목.

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

예를 들어:

  • 일부 섹션이 Premium 및 Ultimate에 적용되고 다른 섹션이 Ultimate에만 적용되는 경우, H1 Tier:는 Premium, Ultimate여야 합니다.
  • 일부 섹션이 모든 인스턴스에 적용되고 다른 섹션이 Self-managed에만 적용되는 경우, Offering:는 GitLab.com, Self-managed, GitLab Dedicated여야 합니다.
  • 일부 섹션이 베타이고 다른 섹션이 실험인 경우, H1 Status:는 Beta여야 합니다.

일부 섹션이 베타이고 다른 섹션이 일반적으로 사용 가능한 경우, H1에는 Status:가 없어야 합니다.

가용성 세부정보를 추가하지 않을 때

다음 페이지에 가용성 세부정보를 할당하지 마십시오:

  • 튜토리얼.
  • 다양한 티어의 기능을 비교하는 페이지.
  • /development 폴더의 페이지. 이러한 페이지는 자동으로 Contribute 배지를 할당받습니다.
  • /solutions 폴더의 페이지. 이러한 페이지는 자동으로 Solutions 배지를 할당받습니다.

또한 기능이 하나의 명확한 구독 티어나 제공이 없을 경우 할당하지 마십시오.

예를 들어, 특정 기능이 GitLab.com에 하나의 티어에 적용되고, 셀프 관리에는 다른 가용성을 가질 때입니다.

이 경우 다음 중 하나 또는 모두를 수행하십시오:

  • NOTE 알림 상자를 사용하여 가용성 세부정보를 설명합니다.
  • 이 정보가 더 적합한 다른 주제 제목 아래에 가용성 세부정보를 추가합니다.
  • H1 아래에 가용성 세부정보를 추가하지 마십시오.

하위 제목에서 티어, 제공 또는 상태 중복

하위 제목이 상위 주제와 동일한 티어, 제공 또는 상태를 갖는 경우, 하위 제목의 배지에서 정보를 반복할 필요가 없습니다.

예를 들어, H1 제목이 다음과 같다면:

# 내 제목

DETAILS:
**Offering:** GitLab.com
**Tier:** Premium, Ultimate

서브 제목이 다른 티어에 적용되지만 동일한 제공을 갖는 경우는 다음과 같습니다:

## 내 제목

DETAILS:
**Tier:** Ultimate

인라인 가용성 세부정보

일반적으로 다른 텍스트와 함께 인라인으로 가용성 세부정보를 추가하지 않아야 합니다.

기능의 단일 진실 출처는 해당 기능이 설명된 주제여야 합니다.

인라인으로 가용성 세부정보를 언급해야 하는 경우, 일반 텍스트로 작성하십시오.

예를 들어, API 주제에 대해:

문제를 할당할 사용자 IDs. Ultimate 전용.

더 많은 예시는 REST API 스타일 가이드를 참조하십시오.

인라인 역사 텍스트

기존 주제에 내용을 추가할 경우, 기존 텍스트와 함께 역사 정보를 인라인으로 추가하십시오.

가능하다면 관련 문제, 병합 요청 또는 에픽에 대한 링크를 포함하십시오.

예를 들어:

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

가용성 세부정보에 대한 관리 문서

인스턴스 관리자 전용 주제는 Self-managed 티어를 가져야 합니다.

인스턴스 관리자 문서에는 종종 다음과 같은 섹션이 포함됩니다:

  • gitlab.rb 또는 gitlab.yml 파일 변경.
  • Rails 콘솔에 액세스하거나 Rake 작업 실행.
  • 관리자 영역에서 작업 수행.

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