InfoGrab DocsInfoGrab Docs

릴리즈 노트

요약

GitLab 릴리즈 노트는 gitlab 리포지터리에 저장됩니다. 릴리즈 노트는 각 릴리즈별 디렉터리에 index.md 파일과 기능별 개별 파일로 구성됩니다. 각 릴리즈에서 프로덕트 매니저는 기능 릴리즈 노트의 머지 리퀘스트와 파일을 생성할 책임이 있습니다.

GitLab 릴리즈 노트는 gitlab 리포지터리에 저장됩니다.

릴리즈 노트는 각 릴리즈별 디렉터리에 index.md 파일과 기능별 개별 파일로 구성됩니다. 예를 들어, 구조는 다음과 유사합니다:

doc/
└─ releases/
   └─ 19/
     └─ gitlab-19-0-released/
     │  ├── index.md
     │  └── featureA-Beta.md
     └─ gitlab-19-1-released/
        ├── index.md
        ├── featureB.md
        └── featureA-GA.md

각 릴리즈에서 프로덕트 매니저는 기능 릴리즈 노트의 머지 리퀘스트와 파일을 생성할 책임이 있습니다. Technical Writing 팀은 다른 모든 디렉터리와 파일을 생성할 책임이 있습니다.

기능 릴리즈 노트 생성#

기능 릴리즈 노트를 생성하려면:

  • 해당 릴리즈와 관련된 디렉터리를 찾습니다. /doc/releases/19/gitlab-19-1-released/와 유사한 경로여야 합니다.

  • 이 디렉터리에 기능 릴리즈 노트용 Markdown 파일을 생성합니다. 파일 이름은 중요하지 않지만, 나중에 식별하기 쉽도록 이름을 지정하는 것이 좋습니다.

  • 아래의 템플릿을 Markdown 파일에 붙여 넣습니다.

  • 메타데이터를 특정 요구 사항에 맞게 조정합니다.

문서 링크는 상대 경로여야 합니다.

  • 작업 항목(work item) 링크가 비공개가 아닌지 확인합니다.

  • 메타데이터 다음에 릴리즈 노트 텍스트를 작성합니다.

125단어 이하로 작성하고, 이미지나 동영상은 포함하지 않습니다.

  • 문서 링크는 허용되지만 상대 경로여야 합니다.

  • 다른 리소스 링크도 허용됩니다.

  • 머지 리퀘스트를 생성합니다:

Release Notes Item 템플릿을 사용하여 설명을 작성하고 진행 상황을 추적합니다.

  • 머지 리퀘스트를 Engineering Manager와 Technical Writer에게 할당하여 검토를 받습니다.

모든 릴리즈 노트는 해당 릴리즈에 포함되기 위해 릴리즈 당일 전 금요일 23:59 UTC까지 머지되어야 합니다.

기능 릴리즈 노트 편집 또는 삭제#

기능 릴리즈 노트를 업데이트하거나 완전히 삭제해야 하는 경우, 요청한 변경 사항으로 머지 리퀘스트를 만들고 Technical Writer에게 할당하여 검토를 받습니다.

기능 릴리즈 노트를 삭제하려면 관련 파일만 삭제하면 됩니다. 다른 파일은 조정할 필요가 없습니다.

주목할 만한 기여자 추가#

Developer Relations는 각 릴리즈마다 주목할 만한 기여자에 대한 몇 문장을 추가하는 머지 리퀘스트를 생성합니다. 이 정보는 마이너 릴리즈 인덱스 파일에 추가되어야 합니다. 예를 들어, doc/releases/19/gitlab-19-1-released/index.md에 추가합니다.

기존 소개 텍스트 다음에 아래 템플릿을 사용합니다:

## Notable contributor

We are excited to recognize [Name](https://gitlab.com/<username>)
as this month's [Notable Contributor](https://contributors.gitlab.com/notable-contributors)! ...

이 머지 리퀘스트는 릴리즈 전 언제든지 머지할 수 있지만, 작성자에게 확인할 수 있습니다.

기능 릴리즈 노트 검토#

머지 리퀘스트가 생성된 후, Technical Writer는 메타데이터와 본문 텍스트를 검토해야 합니다. 이 프로세스는 다른 문서 변경 사항과 유사합니다.

릴리즈 노트 게시#

릴리즈 당일, 다음 릴리즈를 담당하는 Technical Writer는 세 가지 머지 리퀘스트를 생성합니다:

릴리즈 매니저가 패키지가 공개적으로 제공된다고 확인할 때까지(보통 14:00 UTC 경) 변경 사항을 머지하지 마십시오. 릴리즈 매니저는 게시할 준비가 되면 #release-post 채널에 메모를 추가합니다.

현재 릴리즈의 콘텐츠 업데이트#

게시 프로세스의 일환으로, 마이너 릴리즈 인덱스 파일을 업데이트해야 합니다.

현재 릴리즈의 콘텐츠를 업데이트하려면:

마이너 릴리즈 인덱스 파일을 엽니다. 예를 들어 doc/releases/19/gitlab-19-0-released/index.md.

메타데이터에서 group 다음에 릴리즈 날짜를 추가합니다. 예를 들어:

date: 2026-05-21

이 추가로 파이프라인은 릴리즈 날짜까지 실패합니다. 이 실패는 예상된 것입니다.

description 메타데이터를 업데이트합니다:

# Original
description: Summary of features included in <version>

# New
description: GitLab <version> released with <top feature title>

버전과 주요 기능 제목을 관련 정보로 교체합니다.

title 메타데이터를 업데이트합니다:

# Original
title: GitLab <version> - not yet released

# New
title: GitLab <version>

소개 텍스트를 업데이트합니다:

# Original
The following features are being delivered for GitLab <version>.
These features are now available on GitLab.com.

# New
On <release date>, GitLab <version> was released with the following features.

날짜와 버전을 관련 정보로 교체합니다.

다음 릴리즈의 콘텐츠 생성#

게시 프로세스의 일환으로, 다음 릴리즈의 디렉터리와 콘텐츠를 생성해야 합니다. 예를 들어, 19.1을 게시할 때 19.2의 디렉터리와 인덱스 파일을 생성합니다.

다음 릴리즈의 콘텐츠를 생성하려면:

/doc/releases/에서 메이저 버전 디렉터리를 찾습니다. 예를 들어 /doc/releases/19/.

다음 버전의 콘텐츠를 생성합니다:

다음 릴리즈를 위한 새 디렉터리를 생성합니다. 예를 들어, 19/gitlab-19-1-released/.

  • 새 디렉터리에 다음 릴리즈를 위한 index.md 파일을 생성합니다. 예를 들어, 19/gitlab-19-1-released/index.md.

  • 템플릿을 붙여 넣고 버전 번호를 업데이트합니다.

메이저 버전 인덱스 페이지에 파일을 추가합니다.

/doc/releases/의 메이저 버전 디렉터리로 이동합니다. 예를 들어 /doc/releases/19/.

  • _index.md에서 카드 숏코드를 업데이트하여 다음 릴리즈 파일을 참조합니다. 예를 들어:
<ul class="card-grid">
<li><a href="gitlab-19-0-released/">GitLab 19.0</a></li>
<li><a href="gitlab-19-1-released/">GitLab 19.1</a></li>
</ul>

다음 릴리즈를 참조하도록 예정된 리다이렉트 페이지를 업데이트합니다.

doc/releases/upcoming.md에서 리다이렉트 메타데이터를 업데이트하여 다음 릴리즈 파일을 가리키도록 합니다. 예를 들어:

---
redirect_to: '19/gitlab-19-1-released/index.md'
---

머지 리퀘스트를 생성하고 Technical Writer에게 할당하여 검토를 받습니다.

현재 릴리즈를 네비게이션에 추가#

docs-gitlab-com 리포지터리에서 data/en-us/navigation.yaml에 현재 릴리즈를 추가합니다. 예를 들어:

        - title: GitLab 19
          url: 'releases/19/'
          submenu:
            - title: GitLab 19.0
              url: 'releases/19/gitlab-19-0-released/'
            - title: GitLab 19.1
              url: 'releases/19/gitlab-19-1-released/'

이제 커밋을 푸시할 수 있습니다. 이 머지 리퀘스트는 완료되었습니다.

최종 릴리즈 노트 백포트#

릴리즈 노트가 게시된 후 백포트해야 합니다. 이 작업은 릴리즈 당일에 수행해야 하며, 그 이전에는 수행하지 않습니다.

gitlab 리포지터리의 최종 마감일은 릴리즈 전 금요일입니다. 사용자가 문서 사이트의 오른쪽 상단에서 버전을 선택하면 최종 노트를 볼 수 없습니다. 백포트를 통해 사용자가 새로 릴리즈된 버전을 선택할 때 노트가 표시되고 최신 상태를 유지합니다.

  • "안정 브랜치"를 체크아웃합니다. 예를 들어, 19.1을 릴리즈하는 경우 19-1-stable-ee를 체크아웃합니다.

  • gitlab 리포지터리에서 최신 릴리즈 노트를 열고 파일 내용을 복사합니다.

  • 릴리즈 노트의 로컬 버전에 내용을 붙여 넣습니다.

  • 머지 리퀘스트를 열고 Stable branch 템플릿을 선택하여 설명을 작성합니다. 타깃 브랜치를 안정 브랜치(19-1-stable-ee)로 변경합니다.

  • 메인테이너에게 검토 및 머지를 요청합니다. (다른 Technical Writer도 가능합니다.) 브랜치가 아직 잠겨 있으면 #release-post 채널에서 도움을 요청하거나, 브랜치가 머지 가능할 때까지 몇 시간 기다립니다.

  • 머지 후, 새 파이프라인을 생성합니다. Run for branch name or tag에서 배포할 버전을 선택합니다. 이 예시에서는 19.1을 선택한 다음 New pipeline을 선택합니다.

릴리즈 후 콘텐츠 업데이트#

릴리즈 마감 후 릴리즈 노트를 업데이트, 추가 또는 삭제하려면:

  • gitlab 리포지터리를 업데이트합니다.

gitlab 리포지터리의 Markdown 파일을 업데이트하는 머지 리퀘스트를 엽니다.

  • 변경 사항을 적용합니다.

  • Technical Writer에게 검토 및 머지를 요청합니다.

  • 변경 사항을 백포트합니다.

안정 브랜치를 체크아웃합니다. 예를 들어, 19.0을 업데이트하는 경우 19-0-stable-ee를 체크아웃합니다.

  • 이 브랜치에서 변경 사항을 적용합니다.

  • 머지 리퀘스트를 열고 타깃 브랜치를 안정 브랜치(19-0-stable-ee)로 설정합니다.

  • 메인테이너에게 검토 및 머지를 요청합니다. 다른 Technical Writer도 가능합니다.

  • 머지 후, Technical Writer는 docs-gitlab-com에서 관련 안정 브랜치에 대한 새 파이프라인을 실행해야 합니다. Run for branch name or tag에서 배포할 버전을 선택합니다. 이 예시에서는 19.0을 선택한 다음 New pipeline을 선택합니다.

  • https://docs.gitlab.com에서 오른쪽 상단의 버전을 선택하고 노트가 성공적으로 업데이트되었는지 확인합니다.

구성#

릴리즈 포스트에서 각 기능 릴리즈 노트는 기능 릴리즈 노트에 정의된 stage 메타데이터를 기반으로 섹션에 그룹화됩니다. 각 stage는 다음 섹션 중 하나에 매핑됩니다:

섹션 Stage
Primary features -
Agentic Core ai-powered, modelops
Unified DevOps and Security analytics, application_security_testing, create, deploy, knowledge_graph, package, plan, security_risk_management, software_supply_chain_security, verify
Scale and Deployments data_access, database_excellence, developer_experience, foundations, fulfillment, gitlab_dedicated, gitlab_delivery, growth, production_engineering, tenant_scale, unlisted/unknown

섹션은 표에 나열된 순서대로 표시되며, Primary features가 먼저 표시됩니다. 매핑되지 않은 stage는 Scale and Deployments 섹션에 나타납니다. Primary features 섹션에 기능을 추가하려면 level 메타데이터를 사용합니다.

각 섹션에서 기능 릴리즈 노트는 제목별 알파벳 순으로 나열됩니다. 이 순서를 재정의하려면 weight 메타데이터에 값을 정의하고, 숫자가 낮을수록 먼저 표시됩니다.

일반적으로 10의 배수(예: 10, 20, 30)를 사용하여 향후 삽입 여지를 남기고, 노트가 반드시 먼저 나타나야 하는 경우가 아니면 한 자리 숫자는 피합니다.

메타데이터#

마이너 릴리즈 인덱스 메타데이터#

메타데이터 형식 설명
title 릴리즈 전: GitLab - not yet released / 릴리즈 후: GitLab 페이지 제목. 릴리즈 전에는 첫 번째 형식을, 릴리즈 당일에는 두 번째 형식을 사용합니다.
description 릴리즈 전: Summary of features included in / 릴리즈 후: GitLab released with 인덱스 페이지의 카드에 표시되는 짧은 요약입니다.
group Monthly Release, Patch Release 분석 및 피드백에 사용됩니다. 항상 Monthly Release를 사용하며, 패치 릴리즈는 다른 프로세스를 통해 생성됩니다.
stage Release Notes 분석 및 피드백에 사용됩니다. 항상 Release Notes를 사용합니다.

기능 릴리즈 노트 메타데이터#

메타데이터 형식 설명
title string 기능 제목. 섹션 제목으로 표시됩니다. 이상적으로는 7단어 이하입니다.
tier array, formatted like [ Free, Premium, Ultimate ] 기능 티어. 최소 하나 이상 필요합니다. 항상 이 순서를 따릅니다.
offering array, formatted like [ gitlab_com, self_managed, gitlab_dedicated, gitlab_dedicated_for_government ] 기능 오퍼링. 형식이 중요합니다. 최소 하나 이상 필요합니다. 항상 이 순서를 따릅니다.
documentation_link relative URL 기능 문서 링크. https:// 형식의 링크는 사용하지 않으며, _index.md 또는 .md 확장자를 생략합니다.
work_item absolute URL 관련 작업 항목 링크. 비공개가 아니어야 합니다.
categories array 하나 이상의 카테고리 Name 값의 배열. 값은 대소문자를 구분하며, 여러 값은 쉼표로 구분합니다. 관련 카테고리가 없으면 추가하기 위한 다른 머지 리퀘스트를 만듭니다. 19.1의 경우, 본문 텍스트의 HTML 주석에도 카테고리 정보를 추가합니다. 자세한 내용은 템플릿을 참조하세요.
stage string 기능을 생성한 stage 이름. 릴리즈 노트가 나타나는 섹션을 구성하는 데 사용됩니다.
level One of: primary or secondary 선택 사항. Primary features 섹션에서의 배치를 제어합니다. 정의되지 않은 경우 기본값은 secondary입니다.
weight number 선택 사항. 각 섹션 내의 순서를 제어합니다. 숫자가 낮을수록 먼저 표시됩니다. 섹션에서 기능 릴리즈 노트를 강제로 먼저 표시하려면 10과 같은 낮은 숫자를 사용합니다. 다른 기능 릴리즈 노트와의 정렬 문제를 방지하려면, 노트가 반드시 먼저 나타나야 하는 경우가 아니면 한 자리 숫자는 피합니다.
ignore_in_report boolean 내부 도구에 의해 true가 필요합니다. 기능 릴리즈 노트 렌더링에는 영향이 없습니다.

템플릿#

마이너 릴리즈 인덱스#

---
title: "GitLab <version> - not yet released"
description: "Summary of features included in <version>"
group: Monthly Release
stage: Release Notes
---

The following features are being delivered for GitLab <version>.
These features are now available on GitLab.com.

## Notable contributor

기능 릴리즈 노트#

19.1 릴리즈의 경우, 본문 텍스트의 HTML 주석에도 카테고리 정보를 추가합니다. 형식은 다음과 같습니다: <!-- categories: System Access, Permissions -->.

---
title:
tier: [ Free, Premium, Ultimate ]
offering: [ gitlab_com, self_managed, gitlab_dedicated, gitlab_dedicated_for_government ]
stage: application_security_testing
documentation_link: "../../../user/permissions/#groups"
work_item: https://gitlab.com/groups/gitlab-org/-/work_items/<work-item-number>
categories: [ System Access, Permissions ]
level: primary or secondary
weight: 50
ignore_in_report: true
---

<!-- categories: System Access, Permissions -->

The text of the feature release note.

Explain the value of this improvement with 125 words or fewer.
Use phrases that start with, "In previous versions of GitLab, you couldn't... Now you can..."

릴리즈 노트

GitLab v19.1
원문 보기
요약

GitLab 릴리즈 노트는 gitlab 리포지터리에 저장됩니다. 릴리즈 노트는 각 릴리즈별 디렉터리에 index.md 파일과 기능별 개별 파일로 구성됩니다. 각 릴리즈에서 프로덕트 매니저는 기능 릴리즈 노트의 머지 리퀘스트와 파일을 생성할 책임이 있습니다.

GitLab 릴리즈 노트는 gitlab 리포지터리에 저장됩니다.

릴리즈 노트는 각 릴리즈별 디렉터리에 index.md 파일과 기능별 개별 파일로 구성됩니다. 예를 들어, 구조는 다음과 유사합니다:

doc/
└─ releases/
   └─ 19/
     └─ gitlab-19-0-released/
     │  ├── index.md
     │  └── featureA-Beta.md
     └─ gitlab-19-1-released/
        ├── index.md
        ├── featureB.md
        └── featureA-GA.md

각 릴리즈에서 프로덕트 매니저는 기능 릴리즈 노트의 머지 리퀘스트와 파일을 생성할 책임이 있습니다. Technical Writing 팀은 다른 모든 디렉터리와 파일을 생성할 책임이 있습니다.

기능 릴리즈 노트 생성#

기능 릴리즈 노트를 생성하려면:

  • 해당 릴리즈와 관련된 디렉터리를 찾습니다. /doc/releases/19/gitlab-19-1-released/와 유사한 경로여야 합니다.

  • 이 디렉터리에 기능 릴리즈 노트용 Markdown 파일을 생성합니다. 파일 이름은 중요하지 않지만, 나중에 식별하기 쉽도록 이름을 지정하는 것이 좋습니다.

  • 아래의 템플릿을 Markdown 파일에 붙여 넣습니다.

  • 메타데이터를 특정 요구 사항에 맞게 조정합니다.

문서 링크는 상대 경로여야 합니다.

  • 작업 항목(work item) 링크가 비공개가 아닌지 확인합니다.

  • 메타데이터 다음에 릴리즈 노트 텍스트를 작성합니다.

125단어 이하로 작성하고, 이미지나 동영상은 포함하지 않습니다.

  • 문서 링크는 허용되지만 상대 경로여야 합니다.

  • 다른 리소스 링크도 허용됩니다.

  • 머지 리퀘스트를 생성합니다:

Release Notes Item 템플릿을 사용하여 설명을 작성하고 진행 상황을 추적합니다.

  • 머지 리퀘스트를 Engineering Manager와 Technical Writer에게 할당하여 검토를 받습니다.

모든 릴리즈 노트는 해당 릴리즈에 포함되기 위해 릴리즈 당일 전 금요일 23:59 UTC까지 머지되어야 합니다.

기능 릴리즈 노트 편집 또는 삭제#

기능 릴리즈 노트를 업데이트하거나 완전히 삭제해야 하는 경우, 요청한 변경 사항으로 머지 리퀘스트를 만들고 Technical Writer에게 할당하여 검토를 받습니다.

기능 릴리즈 노트를 삭제하려면 관련 파일만 삭제하면 됩니다. 다른 파일은 조정할 필요가 없습니다.

주목할 만한 기여자 추가#

Developer Relations는 각 릴리즈마다 주목할 만한 기여자에 대한 몇 문장을 추가하는 머지 리퀘스트를 생성합니다. 이 정보는 마이너 릴리즈 인덱스 파일에 추가되어야 합니다. 예를 들어, doc/releases/19/gitlab-19-1-released/index.md에 추가합니다.

기존 소개 텍스트 다음에 아래 템플릿을 사용합니다:

## Notable contributor

We are excited to recognize [Name](https://gitlab.com/<username>)
as this month's [Notable Contributor](https://contributors.gitlab.com/notable-contributors)! ...

이 머지 리퀘스트는 릴리즈 전 언제든지 머지할 수 있지만, 작성자에게 확인할 수 있습니다.

기능 릴리즈 노트 검토#

머지 리퀘스트가 생성된 후, Technical Writer는 메타데이터와 본문 텍스트를 검토해야 합니다. 이 프로세스는 다른 문서 변경 사항과 유사합니다.

릴리즈 노트 게시#

릴리즈 당일, 다음 릴리즈를 담당하는 Technical Writer는 세 가지 머지 리퀘스트를 생성합니다:

릴리즈 매니저가 패키지가 공개적으로 제공된다고 확인할 때까지(보통 14:00 UTC 경) 변경 사항을 머지하지 마십시오. 릴리즈 매니저는 게시할 준비가 되면 #release-post 채널에 메모를 추가합니다.

현재 릴리즈의 콘텐츠 업데이트#

게시 프로세스의 일환으로, 마이너 릴리즈 인덱스 파일을 업데이트해야 합니다.

현재 릴리즈의 콘텐츠를 업데이트하려면:

마이너 릴리즈 인덱스 파일을 엽니다. 예를 들어 doc/releases/19/gitlab-19-0-released/index.md.

메타데이터에서 group 다음에 릴리즈 날짜를 추가합니다. 예를 들어:

date: 2026-05-21

이 추가로 파이프라인은 릴리즈 날짜까지 실패합니다. 이 실패는 예상된 것입니다.

description 메타데이터를 업데이트합니다:

# Original
description: Summary of features included in <version>

# New
description: GitLab <version> released with <top feature title>

버전과 주요 기능 제목을 관련 정보로 교체합니다.

title 메타데이터를 업데이트합니다:

# Original
title: GitLab <version> - not yet released

# New
title: GitLab <version>

소개 텍스트를 업데이트합니다:

# Original
The following features are being delivered for GitLab <version>.
These features are now available on GitLab.com.

# New
On <release date>, GitLab <version> was released with the following features.

날짜와 버전을 관련 정보로 교체합니다.

다음 릴리즈의 콘텐츠 생성#

게시 프로세스의 일환으로, 다음 릴리즈의 디렉터리와 콘텐츠를 생성해야 합니다. 예를 들어, 19.1을 게시할 때 19.2의 디렉터리와 인덱스 파일을 생성합니다.

다음 릴리즈의 콘텐츠를 생성하려면:

/doc/releases/에서 메이저 버전 디렉터리를 찾습니다. 예를 들어 /doc/releases/19/.

다음 버전의 콘텐츠를 생성합니다:

다음 릴리즈를 위한 새 디렉터리를 생성합니다. 예를 들어, 19/gitlab-19-1-released/.

  • 새 디렉터리에 다음 릴리즈를 위한 index.md 파일을 생성합니다. 예를 들어, 19/gitlab-19-1-released/index.md.

  • 템플릿을 붙여 넣고 버전 번호를 업데이트합니다.

메이저 버전 인덱스 페이지에 파일을 추가합니다.

/doc/releases/의 메이저 버전 디렉터리로 이동합니다. 예를 들어 /doc/releases/19/.

  • _index.md에서 카드 숏코드를 업데이트하여 다음 릴리즈 파일을 참조합니다. 예를 들어:
<ul class="card-grid">
<li><a href="gitlab-19-0-released/">GitLab 19.0</a></li>
<li><a href="gitlab-19-1-released/">GitLab 19.1</a></li>
</ul>

다음 릴리즈를 참조하도록 예정된 리다이렉트 페이지를 업데이트합니다.

doc/releases/upcoming.md에서 리다이렉트 메타데이터를 업데이트하여 다음 릴리즈 파일을 가리키도록 합니다. 예를 들어:

---
redirect_to: '19/gitlab-19-1-released/index.md'
---

머지 리퀘스트를 생성하고 Technical Writer에게 할당하여 검토를 받습니다.

현재 릴리즈를 네비게이션에 추가#

docs-gitlab-com 리포지터리에서 data/en-us/navigation.yaml에 현재 릴리즈를 추가합니다. 예를 들어:

        - title: GitLab 19
          url: 'releases/19/'
          submenu:
            - title: GitLab 19.0
              url: 'releases/19/gitlab-19-0-released/'
            - title: GitLab 19.1
              url: 'releases/19/gitlab-19-1-released/'

이제 커밋을 푸시할 수 있습니다. 이 머지 리퀘스트는 완료되었습니다.

최종 릴리즈 노트 백포트#

릴리즈 노트가 게시된 후 백포트해야 합니다. 이 작업은 릴리즈 당일에 수행해야 하며, 그 이전에는 수행하지 않습니다.

gitlab 리포지터리의 최종 마감일은 릴리즈 전 금요일입니다. 사용자가 문서 사이트의 오른쪽 상단에서 버전을 선택하면 최종 노트를 볼 수 없습니다. 백포트를 통해 사용자가 새로 릴리즈된 버전을 선택할 때 노트가 표시되고 최신 상태를 유지합니다.

  • "안정 브랜치"를 체크아웃합니다. 예를 들어, 19.1을 릴리즈하는 경우 19-1-stable-ee를 체크아웃합니다.

  • gitlab 리포지터리에서 최신 릴리즈 노트를 열고 파일 내용을 복사합니다.

  • 릴리즈 노트의 로컬 버전에 내용을 붙여 넣습니다.

  • 머지 리퀘스트를 열고 Stable branch 템플릿을 선택하여 설명을 작성합니다. 타깃 브랜치를 안정 브랜치(19-1-stable-ee)로 변경합니다.

  • 메인테이너에게 검토 및 머지를 요청합니다. (다른 Technical Writer도 가능합니다.) 브랜치가 아직 잠겨 있으면 #release-post 채널에서 도움을 요청하거나, 브랜치가 머지 가능할 때까지 몇 시간 기다립니다.

  • 머지 후, 새 파이프라인을 생성합니다. Run for branch name or tag에서 배포할 버전을 선택합니다. 이 예시에서는 19.1을 선택한 다음 New pipeline을 선택합니다.

릴리즈 후 콘텐츠 업데이트#

릴리즈 마감 후 릴리즈 노트를 업데이트, 추가 또는 삭제하려면:

  • gitlab 리포지터리를 업데이트합니다.

gitlab 리포지터리의 Markdown 파일을 업데이트하는 머지 리퀘스트를 엽니다.

  • 변경 사항을 적용합니다.

  • Technical Writer에게 검토 및 머지를 요청합니다.

  • 변경 사항을 백포트합니다.

안정 브랜치를 체크아웃합니다. 예를 들어, 19.0을 업데이트하는 경우 19-0-stable-ee를 체크아웃합니다.

  • 이 브랜치에서 변경 사항을 적용합니다.

  • 머지 리퀘스트를 열고 타깃 브랜치를 안정 브랜치(19-0-stable-ee)로 설정합니다.

  • 메인테이너에게 검토 및 머지를 요청합니다. 다른 Technical Writer도 가능합니다.

  • 머지 후, Technical Writer는 docs-gitlab-com에서 관련 안정 브랜치에 대한 새 파이프라인을 실행해야 합니다. Run for branch name or tag에서 배포할 버전을 선택합니다. 이 예시에서는 19.0을 선택한 다음 New pipeline을 선택합니다.

  • https://docs.gitlab.com에서 오른쪽 상단의 버전을 선택하고 노트가 성공적으로 업데이트되었는지 확인합니다.

구성#

릴리즈 포스트에서 각 기능 릴리즈 노트는 기능 릴리즈 노트에 정의된 stage 메타데이터를 기반으로 섹션에 그룹화됩니다. 각 stage는 다음 섹션 중 하나에 매핑됩니다:

섹션 Stage
Primary features -
Agentic Core ai-powered, modelops
Unified DevOps and Security analytics, application_security_testing, create, deploy, knowledge_graph, package, plan, security_risk_management, software_supply_chain_security, verify
Scale and Deployments data_access, database_excellence, developer_experience, foundations, fulfillment, gitlab_dedicated, gitlab_delivery, growth, production_engineering, tenant_scale, unlisted/unknown

섹션은 표에 나열된 순서대로 표시되며, Primary features가 먼저 표시됩니다. 매핑되지 않은 stage는 Scale and Deployments 섹션에 나타납니다. Primary features 섹션에 기능을 추가하려면 level 메타데이터를 사용합니다.

각 섹션에서 기능 릴리즈 노트는 제목별 알파벳 순으로 나열됩니다. 이 순서를 재정의하려면 weight 메타데이터에 값을 정의하고, 숫자가 낮을수록 먼저 표시됩니다.

일반적으로 10의 배수(예: 10, 20, 30)를 사용하여 향후 삽입 여지를 남기고, 노트가 반드시 먼저 나타나야 하는 경우가 아니면 한 자리 숫자는 피합니다.

메타데이터#

마이너 릴리즈 인덱스 메타데이터#

메타데이터 형식 설명
title 릴리즈 전: GitLab - not yet released / 릴리즈 후: GitLab 페이지 제목. 릴리즈 전에는 첫 번째 형식을, 릴리즈 당일에는 두 번째 형식을 사용합니다.
description 릴리즈 전: Summary of features included in / 릴리즈 후: GitLab released with 인덱스 페이지의 카드에 표시되는 짧은 요약입니다.
group Monthly Release, Patch Release 분석 및 피드백에 사용됩니다. 항상 Monthly Release를 사용하며, 패치 릴리즈는 다른 프로세스를 통해 생성됩니다.
stage Release Notes 분석 및 피드백에 사용됩니다. 항상 Release Notes를 사용합니다.

기능 릴리즈 노트 메타데이터#

메타데이터 형식 설명
title string 기능 제목. 섹션 제목으로 표시됩니다. 이상적으로는 7단어 이하입니다.
tier array, formatted like [ Free, Premium, Ultimate ] 기능 티어. 최소 하나 이상 필요합니다. 항상 이 순서를 따릅니다.
offering array, formatted like [ gitlab_com, self_managed, gitlab_dedicated, gitlab_dedicated_for_government ] 기능 오퍼링. 형식이 중요합니다. 최소 하나 이상 필요합니다. 항상 이 순서를 따릅니다.
documentation_link relative URL 기능 문서 링크. https:// 형식의 링크는 사용하지 않으며, _index.md 또는 .md 확장자를 생략합니다.
work_item absolute URL 관련 작업 항목 링크. 비공개가 아니어야 합니다.
categories array 하나 이상의 카테고리 Name 값의 배열. 값은 대소문자를 구분하며, 여러 값은 쉼표로 구분합니다. 관련 카테고리가 없으면 추가하기 위한 다른 머지 리퀘스트를 만듭니다. 19.1의 경우, 본문 텍스트의 HTML 주석에도 카테고리 정보를 추가합니다. 자세한 내용은 템플릿을 참조하세요.
stage string 기능을 생성한 stage 이름. 릴리즈 노트가 나타나는 섹션을 구성하는 데 사용됩니다.
level One of: primary or secondary 선택 사항. Primary features 섹션에서의 배치를 제어합니다. 정의되지 않은 경우 기본값은 secondary입니다.
weight number 선택 사항. 각 섹션 내의 순서를 제어합니다. 숫자가 낮을수록 먼저 표시됩니다. 섹션에서 기능 릴리즈 노트를 강제로 먼저 표시하려면 10과 같은 낮은 숫자를 사용합니다. 다른 기능 릴리즈 노트와의 정렬 문제를 방지하려면, 노트가 반드시 먼저 나타나야 하는 경우가 아니면 한 자리 숫자는 피합니다.
ignore_in_report boolean 내부 도구에 의해 true가 필요합니다. 기능 릴리즈 노트 렌더링에는 영향이 없습니다.

템플릿#

마이너 릴리즈 인덱스#

---
title: "GitLab <version> - not yet released"
description: "Summary of features included in <version>"
group: Monthly Release
stage: Release Notes
---

The following features are being delivered for GitLab <version>.
These features are now available on GitLab.com.

## Notable contributor

기능 릴리즈 노트#

19.1 릴리즈의 경우, 본문 텍스트의 HTML 주석에도 카테고리 정보를 추가합니다. 형식은 다음과 같습니다: <!-- categories: System Access, Permissions -->.

---
title:
tier: [ Free, Premium, Ultimate ]
offering: [ gitlab_com, self_managed, gitlab_dedicated, gitlab_dedicated_for_government ]
stage: application_security_testing
documentation_link: "../../../user/permissions/#groups"
work_item: https://gitlab.com/groups/gitlab-org/-/work_items/<work-item-number>
categories: [ System Access, Permissions ]
level: primary or secondary
weight: 50
ignore_in_report: true
---

<!-- categories: System Access, Permissions -->

The text of the feature release note.

Explain the value of this improvement with 125 words or fewer.
Use phrases that start with, "In previous versions of GitLab, you couldn't... Now you can..."