OxideTerm 릴리스

OxideTerm 릴리스은(는) 무엇을 하나요?

리포지토리 소유의 자동화를 통해 OxideTerm 릴리스를 게시합니다. 사용자의 완료된 GUI 실행을 릴리스 게이트로 취급하며, 기본적으로 Cargo 테스트를 실행하지 않습니다.

필수 릴리스 입력

릴리스 변경을 수행하기 전에 다음 값을 확인하세요:

• 대상 버전.
• 대상 채널: stable, beta, 또는 gpui-preview.
• 사용자가 GUI 애플리케이션을 실행하고 게시를 승인했다는 명시적 확인.
• 사용자가 minimal, medium, 또는 detailed를 명시적으로 요청한 경우 릴리스 노트 세부 수준; 그 외에는 detailed를 사용합니다.

버전이 명확한 경우에만 채널을 유추합니다. GUI 승인이 없으면 게시 전에 물어보세요. 변경 로그를 준비하거나 드라이 런하는 경우 승인이 필요하지 않습니다.

채널 계약

채널	버전	태그	변경 로그	기본 노트
Stable	X.Y.Z	vX.Y.Z	.github/release-notes/stable-changelog.md	.github/release-notes/stable.md
Beta	X.Y.Z-beta.N	vX.Y.Z-beta.N	.github/release-notes/beta-changelog.md	.github/release-notes/beta.md
GPUI 미리보기	X.Y.Z-gpui-preview.N	gpui-vX.Y.Z-gpui-preview.N	.github/release-notes/gpui-preview-changelog.md	.github/release-notes/gpui-preview.md

다른 태그 접두사를 만들지 마세요. 네이티브 패키지 워크플로우는 release_tag 디스패치 입력을 통해 기존 태그를 받고 해당 태그에서 릴리스 노트를 선택합니다.

워크플로우

1. 리포지토리 상태 검사

OxideTerm 리포지토리 루트에서 작업하세요. AGENTS.md를 읽은 후 다음을 검사합니다:

git status --short --branch
git remote -v
git log -10 --oneline --decorate

게시 원격 및 태그를 가져온 후 태그 사용 가능 여부를 결정합니다:

git fetch origin --tags

브랜치가 업스트림보다 뒤쳐지거나 분기되지 않았는지 확인하고, 대상 태그를 로컬 및 원격에서 검사합니다:

git rev-list --left-right --count HEAD...@{upstream}
git tag --list <tag>
git ls-remote --tags origin refs/tags/<tag> refs/tags/<tag>^{}

사용자의 관련 없는 변경 사항을 보존합니다. 의도한 릴리스 범위를 안전하게 분리할 수 없거나 브랜치가 분기된 경우 중단합니다. 일반 릴리스의 경우 대상 태그가 존재하면 중단합니다. 아래 명시된 취소된 릴리스 복구 절차를 통해서만 기존 태그를 이동합니다.

2. 변경 로그 범위 설정

변경 로그를 작성하기 전에 번들된 도우미를 실행합니다:

python3 .agents/skills/oxideterm-release/scripts/release_context.py \
  --repo . --channel <channel> --version <version>

같은 채널에서 이전에 도달 가능한 태그를 기준선으로 선호합니다:

• Stable은 이전 Stable 태그와 비교합니다.
• Beta는 이전 Beta 태그와 비교합니다.
• GPUI 미리보기는 이전 GPUI 미리보기 태그와 비교합니다.

채널의 첫 번째 릴리스인 경우 세 채널 중 가장 최근에 도달 가능한 릴리스 태그를 부트스트랩 기준선으로 사용합니다. 리포지토리에 이전에 도달 가능한 릴리스 태그가 없는 경우에만 루트 커밋을 사용합니다. 이렇게 하면 첫 번째 베타 또는 프리뷰 변경 로그가 전체 리포지토리를 요약하는 대신 실제 이전 릴리스 이후의 작업으로 범위가 지정됩니다.

도우미는 정확한 범위, 커밋 및 diff 요약을 출력합니다. 또한 의도된 커밋되지 않은 변경 사항을 포함한 실제 변경 사항을 검사합니다:

git diff <previous-tag>..HEAD
git diff
git diff --cached

커밋 제목만으로 릴리스 노트를 작성하지 마세요. 의미 있는 구현 및 사용자 대면 차이점을 읽으세요. 기계적인 버전 범프, 변경 로그 편집, 형식 정리 전용 변경, 릴리스 영향이 없는 내부 세부 사항은 제외합니다.

풀 리퀘스트 및 기여자 확인

모든 릴리스 채널에 대해 노트를 작성하기 전에 정확한 릴리스 범위의 변경 사항을 원래 풀 리퀘스트에 매핑합니다. 도우미의 커밋 목록은 병합 커밋을 제외합니다; 머지, 스쿼시, 리베이스 병합이 귀속될 수 있도록 병합 기록과 GitHub의 commit-to-PR 연결도 검사합니다:

git log --format='%H %s' <previous-tag>..<target-ref>
gh api --paginate repos/<owner>/<repo>/commits/<commit-sha>/pulls \
  --jq '.[] | {number, title, url: .html_url, author: .user.login, merged_at, merge_commit_sha}'
gh pr view <number> --repo <owner>/<repo> \
  --json number,title,url,author,mergedAt,mergeCommit,commits

포함된 각 PR의 번호, URL, 작성자 로그인 및 실제 기여 내역의 작업 매핑을 유지합니다. 여러 커밋에 대해 반환된 PR을 중복 제거합니다. 대상 히스토리 및 diff에 대해 포함 여부를 확인합니다; 병합 날짜만으로 릴리스 범위가 설정되지 않습니다. 체리픽된 변경 사항의 원래 PR 출처를 확인합니다. 완전히 되돌려진 변경 사항은 출시된 기능으로 제시되어서는 안 됩니다.

병합한 사람이나 봇이 아닌 PR 작성자를 사용합니다. 기여자 감사에서 확인된 프로젝트 유지 관리자 및 봇 계정을 제외합니다; GitHub에서 COLLABORATOR 또는 MEMBER로 레이블을 지정했다고 해서 인간 기여자가 유지 관리자라고 가정하지 마세요. 유지 관리자가 후속 수정을 한 경우 외부 PR 작업에 대한 크레딧을 유지합니다. 참조된 이슈 번호는 PR이나 작성자의 증거가 아닙니다. GitHub 조회가 실패하면 작업 노트에 확인되지 않은 귀속을 유지하고 릴리스 노트를 확정하기 전에 해결하세요; 조회 실패를 기여 없음으로 해석하지 마세요.

3. 채널 변경 로그 작성

선택한 변경 로그에 ## <version>을 최신 항목으로 삽입합니다. 제목은 정확히 버전과 일치해야 합니다. .github/scripts/compose_release_notes.py가 이 제목을 사용하여 항목을 찾기 때문입니다. 제목은 추출 경계이며, 게시된 릴리스 본문의 일부가 아닐 수 있습니다.

모든 버전 항목을 이 순서대로 두 개의 완전한 언어 블록(먼저 중국어, 그 다음 영어)으로 작성합니다. 컴포저는 모든 채널의 이중 언어 릴리스 노트 맨 위에 언어 점프 링크를 추가합니다:

## <version>

### 中文

<중국어 요약 및 섹션>

### English

<영어 요약 및 섹션>

두 블록을 구조적으로 정렬합니다: 동일한 결과, 제한 사항, 검증 상태, 업그레이드 요구 사항을 같은 순서로 설명해야 합니다. 자연스러운 릴리스 노트 언어로 번역하고, 정확성을 떨어뜨릴 경우 제품 이름, 명령어, 파일 이름, 프로토콜 이름은 변경하지 않고 유지합니다. 영어와 중국어를 같은 글머리 기호에 병합하지 마세요. 영어 간결한 사용자 지향 과거 시제를 사용하고 중국어 간결한 완료된 작업 표현을 사용합니다. 각 언어의 여는 요약 단락을 한 줄로 유지하여 GitHub 릴리스 편집기가 인위적인 줄 바꿈을 표시하지 않도록 합니다. 관련 커밋을 하나의 결과로 결합하고 원시 커밋 제목 덤프, 구현 사소한 내용, 지원되지 않는 성능 주장, 확인되지 않은 주장을 피합니다. 두 블록의 각 주요 안정 릴리스 섹션 제목에 하나의 절제되고 의미적으로 관련된 이모지를 사용합니다; 모든 글머리 기호를 장식하거나 한 섹션 내에서 여러 이모지 스타일을 혼합하지 마세요.

포크 릴리스의 경우 각 언어 블록은 공식 OxideTerm 업스트림에서 상속된 변경 사항을 포크에서 구현한 변경 사항과 명확히 분리해야 합니다. Upstream changes / 上游更新 및 Fork-specific changes / Fork 自有更新에 해당하는 명시적인 현지화된 제목을 사용합니다; 선택한 세부 수준이 정당화되는 경우 하위 시스템 제목을 그 아래에 중첩할 수 있습니다. 병합되거나 체리픽된 공식 작업은 커밋 작성자와 관계없이 업스트림으로 분류하고, 게시 포크에 고유한 동작은 포크 고유로 분류합니다. 포크가 업스트림 기능을 수정하는 경우 업스트림에서 상속된 기능을 설명하고 포크의 실질적 차이점을 포크 고유 변경 사항 아래에 설명합니다. 릴리스 범위에 변경 사항이 없는 경우 범주를 생략하는 대신 명시적으로 명시합니다. 결합된 요약이나 글머리 기호가 포크가 업스트림 작업을 작성했음을 암시하지 않도록 합니다.

PR 참조 및 기여자 감사

NyaTerm v1.2.12의 귀속 패턴을 따릅니다: PR 참조는 도입된 변경 사항 옆에, 전용 기여자 섹션도 포함합니다. 실제 항목은 OxideTerm의 릴리스 범위에서 파생됩니다.

• PR을 통해 도입된 모든 릴리스 노트 항목에 PR 번호를 링크로 추가합니다(유지 관리자 작성 PR 포함). 중국어에서는 （PR [#<number>](<pr-url>)）, 영어에서는 (PR [#<number>](<pr-url>))을 사용합니다. 관련 글머리 기호 또는 기능 단락 끝에 참조를 배치합니다(기여자 목록이나 전체 변경 로그 링크에만 넣지 않음). 이슈 링크는 PR 링크와 구별합니다. 직접 커밋에는 번호가 부여되지 않습니다.
• 여러 PR이 그룹화된 항목에 기여한 경우 해당 항목에 모든 관련 PR 번호를 한 번 포함합니다. 각 PR이 지원하는 결과만 귀속합니다; 그룹화가 잘못된 작성자를 크레딧할 때 유지 관리자의 독립적인 후속 변경 사항을 분리합니다. 다른 리포지토리의 PR인 경우 링크 레이블을 owner/repo#number로 한정합니다.
• 릴리스에 외부 PR 기여가 포함될 때마다 중국어 블록 내에 #### 👥 贡献者를 추가하고 영어 블록 내에 #### 👥 Contributors를 추가합니다(변경 사항 섹션 뒤에, 업그레이드 노트 앞에). 이 릴리스에 포함된 모든 외부 PR 작성자에게 감사하며, 독립적인 기능 글머리 기호를 보장하지 않을 수 있는 재기여자, 문서, 번역, 빌드 또는 패키징 기여자도 포함합니다.
• 각 언어 블록마다 확인된 GitHub @login, 기여에 대한 간략한 설명, 링크된 PR 번호를 사용하여 각 작성자를 한 번씩 나열합니다. 두 언어에서 작성자와 PR 참조를 일치시킵니다. 일반적인 감사나 GitHub의 자동 아바타 스트립은 이러한 항목을 대체하지 않습니다. 첫 번째 기여자를 식별하는 경우 이전 리포지토리 기여를 확인합니다; New Contributors 목록은 전체 감사 섹션을 보완합니다.
• 모든 세부 수준과 모든 채널에서 귀속을 적용합니다. 확인된 범위에 외부 PR 기여가 없으면 빈 제목을 추가하는 대신 기여자 섹션을 생략합니다. 릴리스 범위 밖의 PR은 이 버전에 대한 새로운 기여로 인정되지 않습니다.

예시 기여자 항목(자리 표시자를 확인된 릴리스 데이터로 대체):

#### 👥 贡献者

感谢以下外部贡献者参与本次更新：

- @<login>：<具体贡献>（PR [#<number>](<pr-url>)）。

#### 👥 Contributors

Thank you to the external contributors to this release:

- @<login>: <specific contribution> (PR [#<number>](<pr-url>)).

두 예시 섹션을 각 언어 블록에 배치하고, 별도의 제3의 이중 언어 섹션으로 함께 배치하지 마세요.

릴리스 노트 세부 수준

영어와 중국어 블록에 동일한 수준을 사용합니다. 수준은 범위와 그룹화를 제어하며, 필수 단어 수가 아닙니다. 더 짧은 수준을 충족하기 위해 중대한 변경, 보안 경계, 업그레이드 요구 사항, 알려진 제한 사항 또는 실질적인 호환성 문제를 절대 생략하지 마세요.

수준	필수 밀도
minimal	사용자가 명시적으로 요청한 경우에만 사용합니다. 하나의 짧은 요약 뒤에 대략 2-5개의 매우 통합된 결과 글머리 기호를 작성하고, 스캔에 실질적으로 도움이 될 때만 최대 하나 또는 두 개의 제목을 사용합니다. 릴리스의 주요 사용자 대면 변경 사항 및 필요한 경고만 다룹니다.
medium	사용자가 명시적으로 요청한 경우에만 사용합니다. 하나의 요약, 소수의 유용한 섹션, 주요 기능, 수정 사항, 보안 또는 호환성 결과를 다루는 그룹화된 글머리 기호를 작성합니다. 관련 지원 워크플로우를 각각 별도로 나열하는 대신 통합합니다.
detailed	사용자가 명시적으로 다른 수준을 선택하지 않는 한 기본값입니다. 의미 있는 하위 시스템 또는 워크플로우별로 노트를 구성하고 각각의 뚜렷한 사용자 대면 기능, 동작 변경, 호환성 수정, 지원되는 제한 사항, 확인된 성능 또는 검증 결과가 diff를 읽지 않고도 이해될 수 있도록 충분한 공간을 제공합니다. 사용자가 변경 사항을 이해하거나 사용하는 방식에 실질적으로 영향을 미치는 경우 지원 워크플로우를 포함하지만, 릴리스에 실제 변경 사항이 적을 때 채우기 항목을 추가하지 마세요.

수준을 범위 및 그룹화 지침으로 취급하고 고정 템플릿으로 취급하지 마세요. 먼저 완전한 실제 차이를 결정한 다음 선택한 수준으로 통합합니다. 사용자가 단순히 "릴리스 노트를 작성하라" 또는 "릴리스를 준비하라"고 말하는 경우 detailed를 사용합니다.

채널별 강조를 적용합니다:

• Stable: 이전 Stable 태그 이후의 완전한 차이를 요약합니다. 각 언어 블록에서 하나의 짧은 릴리스 요약으로 시작한 다음 #### ✨ Highlights / #### ✨ 重点更新, #### 🛠️ Fixes / #### 🛠️ 修复, #### 🔒 Security / #### 🔒 安全, 또는 #### 🧰 Release Maintenance / #### 🧰 发布维护와 같은 유용한 섹션만 사용합니다. 사용자 대면 동작 및 호환성을 강조합니다. 구성된 GitHub 릴리스 본문은 [中文](#中文) | [English](#english) 탐색으로 시작하고, 그 다음 완전한 ### 中文 블록과 이어서 일치하는 ### English 블록으로 구성되며, # OxideTerm 2.0과 같은 제품 주요 제목과 ## 2.0.7과 같은 반복 버전 제목은 생략하고, 두 언어 블록 뒤에 ## 📥 Download for your system, 설치 팁 및 링크를 배치합니다.
• Beta: 완전한 영어 및 중국어 블록으로 이전 Beta 태그 이후의 차이를 요약합니다. 안정에 가까워지고 있는 것, 변경된 사항, 검증이 필요한 워크플로우를 명시합니다. diff 또는 이슈 컨텍스트에서 지원되는 경우에만 알려진 제한 사항을 언급하고 두 언어에 모두 포함합니다.
• GPUI 미리보기: 완전한 영어 및 중국어 블록으로 이전 GPUI 미리보기 태그 이후의 차이를 요약합니다. 새로 테스트 가능한 네이티브 UI/런타임 작업, 패리티, 거친 가장자리 및 구체적인 테스트 대상에 초점을 맞춥니다. 선택한 세부 수준을 적용하면서 작성은 테스트 지향적으로 유지하고 프리뷰 노트를 안정 릴리스 마케팅으로 바꾸지 마세요.

해당 채널에 대한 이전 태그가 없는 경우 부트스트랩 기준선으로 사용된 이전 릴리스 태그를 명시합니다.

4. 리포지토리 버전 스크립트 실행

항상 리포지토리 스크립트를 사용합니다. 작업 공간 버전이나 lockfile을 수동으로 편집하지 마세요:

python3 scripts/release/bump_version.py <version>

이 스크립트는 SemVer를 검증하고 [workspace.package]를 업데이트하며 오프라인으로 Cargo.lock을 새로 고칩니다. README 배지는 최신 GitHub 릴리스를 자동으로 표시하므로 버전 편집이 필요하지 않습니다.

5. 간단한 릴리스 검증 수행

cargo test를 실행하지 않고…

[나머지 내용 번역됨]