OpenClaw 릴리스 메인테이너

OpenClaw 릴리스 메인테이너은(는) 무엇을 하나요?

이 스킬은 릴리스 및 게시 시간 워크플로에 사용됩니다. 일반 개발 변경 사항과 GHSA 관련 어드바이저리 작업은 이 스킬 외부에서 처리하세요.

릴리스 가드레일 준수

• 명시적인 운영자 승인 없이 버전 번호를 변경하지 마십시오.
• npm 게시 또는 릴리스 단계 전에 반드시 허가를 요청하세요.
• 이 스킬은 일반 릴리스 흐름을 종단간(end-to-end)으로 실행하기에 충분해야 합니다.
• 비공개 메인테이너 릴리스 문서에는 자격 증명, 복구 단계, Mac 서명/공증 관련 세부 사항이 포함되어 있으며, docs/reference/RELEASING.md는 공개 정책을 담고 있습니다.
• 핵심 openclaw 게시는 수동 workflow_dispatch입니다. 태그를 생성하거나 푸시하는 것만으로는 게시되지 않습니다.
• 일반 릴리스 작업은 main에서 분기된 브랜치에서 이루어지며, main에서 직접 작업하지 않습니다. 브랜치 이름은 release/YYYY.M.D를 사용하세요.
• 운영자가 stable/full을 명시하지 않고 릴리스를 요청하면 기본값으로 beta만 진행합니다. 운영자가 명시적으로 전체 릴리스 또는 자동화된 베타-안정 트레인(automated beta-and-stable train)을 요청할 때만 beta에서 stable로 전환하세요.
• 릴리스 브랜칭 전에 최신 main을 가져오고 현재 main CI가 통과했는지 확인하세요. 그런 다음 해당 커밋에서 브랜치를 생성하여 일반 개발이 main에서 계속 진행될 수 있도록 하고 릴리스 검증이 실행됩니다.
• 릴리스 브랜칭 전에 더티 파일을 일관된 그룹으로 커밋하고, 푸시, 풀/리베이스한 다음 main에서 /changelog를 실행하고 변경 로그 재작성을 커밋/푸시/풀한 후 즉시 릴리스 브랜치를 생성하세요.
• 릴리스 계획 중에 브랜칭 전과 최종 게시 전에 src/plugins/compat/registry.ts와 src/commands/doctor/shared/deprecation-compat.ts를 모두 검사하세요. removeAfter 날짜가 릴리스 날짜와 같거나 이전인 모든 비권장 또는 제거 예정 호환성 레코드에 대해 안전한 경우 호환성 경로를 제거하고 영향을 받는 테스트를 검증하거나, 제거가 차단된 이유를 기록하고 명시적인 메인테이너 승인을 받은 후 만료된 호환성 경로를 제공하세요.
• 비권장 런타임/설정 호환성을 제거할 때 지원되는 업그레이드 경로에 여전히 필요한 doctor 마이그레이션, 복구 또는 힌트를 보존하세요. Doctor 측 호환성은 메인테이너가 복구가 더 이상 필요하지 않음을 확인할 때까지 src/commands/doctor/shared/deprecation-compat.ts에서 추적되어야 합니다.
• 릴리스 계획 중에 호환성 대체 텍스트를 재검증하세요. 권장 대체는 플러그인 소유권, 외부화 및 설정 범위가 이동함에 따라 변경될 수 있으므로 릴리스 노트에 오래된 대체 주석을 맹목적으로 복사하지 마세요.
• 일치하는 npm 패키지가 게시된 후에는 베타 태그를 삭제하거나 다시 쓰지 마세요. 푸시된 베타 태그가 npm 게시 전에 실패하면 버전이 사용되지 않은 것입니다. 동일한 -beta.N을 유지하고 git 태그와 프리릴리스를 수정된 커밋에 대해 삭제/재생성하거나 강제 이동하고 사전 비행을 다시 실행하세요. 일치하는 npm 패키지가 실제로 게시될 때까지 다음 베타 번호로 증가시키지 마세요. 게시된 베타에 수정이 필요한 경우 릴리스 브랜치에 수정 사항을 커밋하고 다음 -beta.N으로 증가시키세요.
• 베타 릴리스 트레인의 경우 빠른 로컬 사전 비행을 먼저 실행하고 베타를 npm beta에 게시한 다음 설치/업데이트/Docker/Parallels/NPM Telegram에 초점을 맞춘 비용이 많이 드는 게시 패키지 로스터(roster)를 실행하세요. 실패하면 릴리스 브랜치에서 수정하고, 커밋/푸시/풀하고, 베타 번호를 증가시킨 후 반복하세요. stable/latest 프로모션 전에 최소 한 번은 전체 비용이 많이 드는 로스터를 실행하세요. 이후 베타 시도에서는 수정 사항이 광범위한 릴리스, 설치/업데이트, 플러그인, Docker, Parallels 또는 라이브 QA 동작에 영향을 미치지 않는 한 변경된 증거가 있는 레인만 다시 실행하세요. 각 베타가 게시된 후 릴리스 브랜치 커트 이후에 적용된 중요한 수정 사항이 있는지 현재 main을 한 번 스캔하고 중요한 저위험 수정만 백포트하세요. 운영자는 최대 4개의 자율 베타 시도를 승인할 수 있습니다. 4번의 베타 시도가 실패하면 중단하고 보고하세요.
• 버전/태그 준비 전에 /changelog를 사용하여 최상위 변경 로그 섹션이 중복 제거되고 사용자 영향 순서로 정렬되도록 하세요.
• 베타 전용 CHANGELOG.md 헤딩을 생성하지 마세요. 베타 릴리스는 안정 기본 버전 섹션을 사용합니다. 예를 들어 v2026.4.20-beta.1은 ## 2026.4.20 릴리스 노트를 사용합니다.
• 베타 또는 안정 릴리스가 라이브 상태가 되면 설정된 비밀 워크플로를 사용하여 최선의 노력으로 Discord 공지를 하세요. 공지가 실패해도 릴리스를 차단하거나 롤백하지 마세요.
• X에 공지하라는 요청을 받으면 ~/Projects/bird/bird를 사용하고 아래 릴리스 트윗 스타일을 따르세요.

릴리스 채널 명명 규칙 준수

• stable: 태그된 릴리스만 해당, 기본적으로 npm beta에 게시됨. 운영자는 명시적으로 npm latest를 대상으로 하거나 나중에 프로모션할 수 있음
• beta: vYYYY.M.D-beta.N 형식의 프리릴리스 태그, npm dist-tag beta 사용
• -beta.N을 선호하며, 새로운 -1 또는 -2 베타 접미사를 만들지 마세요
• dev: main의 이동 헤드
• 베타 Git 태그를 사용할 때는 일반 버전이 사용되거나 차단되지 않도록 일치하는 베타 버전 접미사로 npm을 게시하세요.

버전 및 릴리스 파일 일관성 유지

• 버전 위치는 다음을 포함합니다:
  • package.json
  • apps/android/app/build.gradle.kts
  • apps/ios/Sources/Info.plist
  • apps/ios/Tests/Info.plist
  • apps/macos/Sources/OpenClaw/Resources/Info.plist
  • docs/install/updating.md
  • Peekaboo Xcode 프로젝트 및 plist 버전 필드
• 릴리스 태그를 생성하기 전에 위의 모든 버전 위치가 해당 태그로 인코딩된 버전과 일치하는지 확인하세요.
• vYYYY.M.D-N과 같은 폴백 수정 태그의 경우 리포지토리 버전 위치는 여전히 YYYY.M.D를 유지합니다.
• "모든 곳에서 버전 범프"는 위의 모든 버전 위치(appcast.xml 제외)를 의미합니다.
• 릴리스 서명 및 공증 자격 증명은 리포지토리 외부의 비공개 메인테이너 문서에 있습니다.
• 모든 안정 OpenClaw 릴리스는 npm 패키지와 macOS 앱을 함께 제공합니다. 베타 릴리스는 일반적으로 npm/패키지 아티팩트를 먼저 제공하고 운영자가 Mac 베타 검증을 요청하지 않는 한 Mac 앱 빌드/서명/공증을 건너뜁니다.
• 느린 macOS 서명/공증 경로가 npm 사전 비행이 통과한 후 npm 게시를 차단하지 않도록 하세요. Mac 검증/게시를 병렬로 계속 실행하고, 성공한 npm 사전 비행에서 npm을 게시한 다음, Mac 아티팩트가 계속 진행되는 동안 게시된 npm 설치/업데이트, Docker 및 Parallels 검증을 시작하세요.
• 베타가 게시된 후에는 유용한 경우 원격/수동 릴리스 로스터를 중첩하되, 동일한 호스트에 로컬 Docker, Parallels 및 QA-Lab 작업이 시스템 부하를 유발할 수 있는 경우 쌓지 마세요. 실패 또는 수정 후에는 선택적으로 재실행하되, stable/latest 프로모션 전에 Docker, Parallels 및 QA-Lab이 각각 최소 한 번은 통과했음을 입증해야 합니다.
• Mac 패키징은 델타가 Mac 패키징, 서명, 워크플로 또는 검증 전용 릴리스 메커니즘인 경우 태그된 커밋의 약간의 릴리스 브랜치 변형에서 빌드될 수 있습니다. 안정 npm 패키지 또는 GitHub 태그가 이미 게시된 후 Mac 패키징에 릴리스 브랜치 전용 수정이 필요한 경우 워크플로 소스를 변경하기 위해 vYYYY.M.D-N 수정 태그를 생성하지 마세요. source_ref=release/YYYY.M.D 및 public_release_branch=release/YYYY.M.D와 함께 원래 tag=vYYYY.M.D에 대한 비공개 Mac 워크플로를 디스패치하세요. 출처 점검은 소스 SHA가 태그에서 파생되고 검증/사전 비행이 동일한 소스를 사용함을 증명해야 합니다. vYYYY.M.D-N 수정 태그는 새로운 npm 패키지/릴리스 ID를 게시해야 하는 긴급 핫픽스를 위해 예약하고, 일반적인 Mac 전용 패키징 복구에는 사용하지 마세요.
• 프로덕션 Sparkle 피드는 https://raw.githubusercontent.com/openclaw/openclaw/main/appcast.xml에 있으며, 표준 게시 파일은 openclaw 리포지토리의 main에 있는 appcast.xml입니다.
• 공유된 프로덕션 Sparkle 피드는 안정 전용입니다. 베타 Mac 릴리스는 GitHub 프리릴리스에 자산을 업로드할 수 있지만, 별도의 베타 피드가 없는 한 공유된 appcast.xml을 대체해서는 안 됩니다.
• vYYYY.M.D-N과 같은 폴백 수정 태그의 경우 리포지토리 버전은 여전히 YYYY.M.D에 머물지만, Mac 릴리스는 기존 설치에서 더 새로운 것으로 인식되도록 원래 릴리스보다 엄격히 더 높은 숫자의 APP_BUILD / Sparkle 빌드를 사용해야 합니다.

변경 로그 기반 릴리스 노트 구축

• 릴리스 브랜칭 또는 태깅 전에 대상 CHANGELOG.md 섹션을 기존 노트뿐만 아니라 커밋 기록에서 다시 작성하세요. 마지막 도달 가능한 릴리스 태그 이후의 커밋을 스캔하고, 누락된 사용자 대면 변경 사항을 추가하고, 중복 항목을 제거하고, 각 섹션을 사용자에게 가장 흥미로운 순서로 정렬하세요.
• 변경 로그 항목은 사용자 대면이어야 하며 내부 릴리스 프로세스 노트가 아니어야 합니다.
• GitHub 릴리스 및 프리릴리스 본문은 전체 일치하는 CHANGELOG.md 버전 섹션을 사용해야 하며, 하이라이트나 발췌문을 사용하지 마세요. 릴리스를 생성하거나 편집할 때 ## YYYY.M.D부터 다음 레벨 2 헤딩 앞의 줄까지 추출하여 해당 완전한 블록을 릴리스 노트로 사용하세요.
• 릴리스 노트를 준비할 때 src/plugins/compat/registry.ts 및 src/commands/doctor/shared/deprecation-compat.ts에서 warningStarts 또는 removeAfter가 릴리스 날짜 후 7일 이내인 호환성 레코드를 스캔하세요. 존재하는 경우 릴리스 노트에 예정된 비권장 사항 노트를 추가하고, 호환성 코드, 대상 날짜, 대체 및 레코드의 docsPath 또는 더 구체적인 비권장 페이지가 없을 때 /plugins/compatibility에 대한 링크를 포함하세요.
• 베타 GitHub 프리릴리스로 Mac 릴리스를 만들 때:
  • 릴리스 커밋에서 vYYYY.M.D-beta.N 태그
  • openclaw YYYY.M.D-beta.N 제목의 프리릴리스 생성
  • 안정 기본 CHANGELOG.md 버전 섹션(## YYYY.M.D)의 릴리스 노트 사용, 베타 전용 헤딩 사용 금지
  • 최소한 zip 및 dSYM zip, 가능하면 dmg도 첨부
• CHANGELOG.md의 상위 버전 항목을 영향 순서로 유지:
  • ### 변경 사항 먼저
  • ### 수정 사항 중복 제거, 사용자 대면 수정 먼저

릴리스 트윗 작성

OpenClaw 계정의 기존 릴리스 게시 스타일 사용:

• 형식: OpenClaw YYYY.M.D 🦞 또는 🦞 OpenClaw YYYY.M.D가 라이브입니다, 빈 줄, 그 다음 3-4개의 이모지 불릿, 빈 줄, 하나의 짧은 punchline, 그 다음 릴리스 링크.
• 베타의 경우: OpenClaw YYYY.M.D-beta.N 🦞 또는 OpenClaw YYYY.M.D beta N이 라이브입니다라고 말하고, 명확하게 베타임을 표시하고 안정 프로모션을 암시하지 마세요.
• 사용자에게 보이는 기능, 그 다음 중요한 통합, 그 다음 안정성/보안/설치 수정으로 이끄세요. "많은 수정"을 하나의 읽기 쉬운 불릿으로 압축하세요.
• 초안을 작성하기 전에 전체 변경 로그 섹션을 읽으세요. 적용 범위, CI, 검증 또는 내부 릴리스 메커니즘으로 시작하지 마세요(릴리스가 명시적으로 해당 내용에 관한 것이 아니지 않는 한). Peter는 구체적인 사용자 이점(기능, 통합, 워크플로 개선, 실용적인 안정성 수정)을 선호합니다.
• 사용자 대면 출시 트윗에서 QA 패리티, 테스트 커버리지, 릴리스 게이트 또는 검증 레인을 다루지 마세요. 운영자가 명시적으로 검증 중심 콘텐츠를 요청하지 않는 한 릴리스 노트 또는 메인테이너 증명용으로 유지하세요.
• 운영자가 명시적으로 개발자 중심 콘텐츠를 요청하지 않는 한 일반 사용자 대면 출시 트윗에서 플러그인 작성자 또는 개발자 도구(SDK 도우미, 도구-플러그인 스캐폴딩, 빌드/검증/초기화 명령 또는 내부 CLI 배관)를 다루지 마세요.
• 어조: 정보 밀도 높고, 약간 건방지고, 자신감 있고, 기업체 스타일 금지. 농담은 하나면 충분합니다. 사용자를 비하하거나, 모욕하거나, 검증되지 않은 것을 약속하지 마세요.
• Peter는 마른 밀도 높은 태그라인이 적절할 때를 좋아합니다. 좋은 예: Big release, tiny release notes... kidding. 농담을 짧게 유지하고 기능 불릿이 트윗을 이끌도록 하세요. punchline을 두 번째 문단이나 억지 요소로 만들지 마세요.
• 길이: 릴리스 트윗은 항상 URL 하나를 위한 공간이 있는 280자 미만의 표준 트윗입니다. 3-4개의 불릿으로 다듬고 게시 전에 최종 텍스트를 세어보세요.
• 링크/미디어: 첫 번째 릴리스 트윗 끝에 GitHub 릴리스 또는 변경 로그 링크를 포함하세요.
• 스레드 후속: 스레드를 하는 경우 첫 번째 릴리스 트윗을 간결한 출시 게시글로 유지한 다음 답글당 하나의 집중 기능 설명을 게시하세요. 후속 답글은 스레드 컨텍스트가 이미 명확할 때 "VERSION의 새로운 기능" 또는 버전 번호를 반복하지 않아야 합니다.
• Peter의 선호 스레드 워크플로: 먼저 일반 출시 트윗에 동의한 다음 하나씩 후속 트윗을 진행합니다. 그가 next라고 말하면 다음 후속 트윗만 제공하거나 복사하세요. 요청하지 않는 한 전체 스레드를 다시 덤프하지 마세요.
• 모든 후속 트윗에는 해당 특정 기능에 대한 문서 URL이 포함되어야 합니다. 명확성을 위해 레이블이 필요하지 않은 한 Docs: <url>보다는 일반 URL을 선호하세요. 후속 트윗을 간결하게 유지하세요. 일반적으로 약 160-220 원시 문자가 적절하며, 280 미만이 하드 상한선입니다. URL로 인해 트윗이 실패하는 경우 URL을 삭제하기 전에 산문을 다듬으세요. 설정이 많은 기능(진단, 궤적/내보내기, 공급자 설정, 모델 명령 등)을 첫 번째 릴리스 트윗에 과부하시키는 대신 후속 트윗에서 설명하는 것을 선호하세요.
• 핫픽스/수정: 직접적이고 책임감 있게 대응하세요. 무엇이 누락되었는지, 무엇이 수정되었는지, 새 버전이 무엇인지 명시하세요. 사고 스타일 게시물에는 농담을 넣지 마세요.

적응할 예시:

OpenClaw 2026.4.20-beta.1 🦞

🐳 Docker 설치/업데이트 연기
🖥️ Parallels 업그레이드 점검
🔧 패키지 검증 강화

베타 우선. 시련 후 안정.
<릴리스 링크>

OpenClaw 2026.4.20 🦞

🚀 더 빠른 설치 + 업데이트
🐳 Docker + Parallels 검증 완료
🍎 macOS 서명 + 공증 완료
🔧 채널/플러그인 수정

좋은 지루한 릴리스. 가장 좋은 종류.
<릴리스 링크>

2026.4.20-beta.1에 패키징 문제.

2026.4.20-beta.2는 설치/업데이트 검증을 수정합니다. 태그 재작성 없음. 베타는 앞으로 진행됩니다.

베타 채널로 업그레이드하세요.
<릴리스 링크>

게시 시간 검증 실행

태깅 또는 게시 전에 다음을 실행하세요:

pnpm check:architecture
pnpm build
pnpm ui:build
pnpm qa:otel:smoke
pnpm release:check
pnpm test:install:smoke

• 릴리스 검증에 텔레메트리 커버리지가 필요할 때 pnpm qa:otel:smoke를 사용하세요. 로컬 OTLP/HTTP 트레이스 수신기를 시작하고, QA-lab의 otel-trace-smoke를 실행하며, 외부 Opik 또는 기타 서비스 없이 스팬 이름과 콘텐츠/식별자 난독화를 확인합니다.

---

(위 내용은 번역되었으며, 원본 마크다운의 구조와 코드 블록은 유지되었습니다.)