에디션 릴리스

이 문서는 에디션 릴리스를 관리하는 방법을 개략적으로 설명합니다. 이 문서는 독자가 에디션이 무엇인지 이미 알고 있다고 가정합니다(에디션 가이드를 참고하십시오).

에디션 프로젝트 그룹

RFC 3501은 에디션 관리를 책임지는 프로젝트 그룹을 구성하는 일이 리더십 위원회의 책임이라고 규정했습니다.

프로젝트 그룹 리드

프로젝트 그룹에는 리드를 두세 명 두는 것을 권장합니다. 그래야 비교적 촉박한 일정 안에서 필요한 결정과 조치를 더 쉽게 조율하고 신속하게 내릴 수 있습니다.

또 다른 고려 사항은 헌신과 가용 시간입니다. Rust에서 하는 대부분의 작업과 달리 에디션에는 정해진 일정이 있습니다. 따라서 평소와는 다른 종류의 헌신이 필요합니다. 평소에는 사람들이 합류하거나 떠나거나 예기치 않은 지연을 겪더라도 우리 체계가 꽤 너그럽게 받아들입니다. 에디션에서는 그럴 여지가 더 적습니다. 리드는 정기적으로 회의에 참석하고 조치 항목을 제때 후속 처리하겠다고 약속할 수 있어야 합니다. (물론 이런저런 일이 생기기도 하고 휴가를 가기도 하는 등 여러 사정이 있을 수 있으며, 그런 경우에는 어떻게든 대처하여 해낼 것입니다. 하지만 무슨 뜻인지는 이해하실 것입니다.)

또 하나 고려할 점은 필요한 시간이 달마다 크게 달라진다는 것입니다. 할 일이 전혀 없는 달도 있고, 상당히 많은 시간(한 주에 10시간 이상)이 필요한 달도 몇 번 있을 수 있습니다. 이는 에디션에 포함되는 변경 사항이 얼마나 많은지에 따라서도 크게 달라집니다.

프로젝트 그룹 구성원

에디션 프로젝트 그룹의 추가 구성원은 비교적 단기적인 조치 항목을 돕거나 프로세스의 특정 측면(문서 작성, 마이그레이션 린트 구현, 버그 수정, 진행 상황 업데이트 및 블로그 게시물 작성 등)을 도울 수 있습니다.

단계

에디션을 진행하려면 프로젝트 전반에 걸쳐 조율되는 여러 단계를 거쳐야 합니다.

준비 단계. 에디션이 출시되기 약 1년에서 3년 전의 시기로, 모든 준비 작업이 이 단계에 포함됩니다. 이러한 작업은 빨리 수행할수록 좋습니다.
1. 다음 에디션에 대한 예비 지원을 도구에 추가해야 합니다. 앞으로는 이를 자동화하는 것도 좋을 것입니다. 예시:
2. 각 팀이 제안 및 구현 작업을 시작합니다.
리더십 위원회가 에디션을 운영할 프로젝트 그룹을 구성합니다(최종 릴리스 약 1년 전).
최종 마감 단계입니다. 에디션 릴리스 약 1년 전부터 시작되는 기간입니다. 이 시점부터 에디션에 추가될 모든 항목에 대한 일련의 최종 마감이 시작됩니다. 한 해 동안의 마감 일정은 아래의 예시 일정을 참고하십시오.

기능 단계

각 기능은 일련의 단계를 거칩니다. 이 과정은 언제든지 시작할 수 있습니다. 이 과정에 걸리는 시간은 매우 다양하여, 아주 빨리 끝나기도 하고 여러 해가 걸리기도 합니다.

개인과 팀이 에디션 변경을 제안합니다. 정확한 절차는 팀마다 다르지만, 일반적으로는 IRLO에 Pre-RFC를 게시하는 것으로 시작합니다.
제안하는 에디션 변경 사항과 함께 RFC를 게시해야 합니다.
팀이 RFC를 승인합니다. 이는 팀이 원칙적으로 그 아이디어를 원한다는 뜻이지만, 특정 에디션에 맞춰 반영된다는 것을 보장하지는 않습니다.
RFC 또는 팀은 이전 에디션으로부터의 마이그레이션을 어떻게 처리할지 정의하는 마이그레이션 계획을 마련해야 합니다. 일부 유형의 호환성 깨짐 때문에 사람들이 코드를 직접 수정해야 하는 것은 괜찮지만, 그런 경우는 드물어야 하며, 이상적으로는 눈에 잘 띄어야 합니다(즉, 런타임에 예상치 못한 의미 변화가 생기는 것이 아니라 컴파일 오류가 발생해야 합니다). 무엇이 “충분히 드문” 것인지는 에디션 리드가 판단합니다.
기능과 마이그레이션 지원을 구현합니다.
해당 기능에 가장 관심이 많은 사람들이 nightly에서 비공식 테스트를 진행해야 합니다. 이 기간 동안 이슈를 찾아내고 수정해야 합니다.
기능을 담당하는 팀은 기능 마감일까지 해당 기능이 다음 에디션에 포함될 준비가 되었는지 최종 결정을 내려야 합니다. 이 결정은 에디션 프로젝트 그룹과 함께 내려야 합니다.
에디션 가이드와 레퍼런스 같은 곳에 변경 사항을 문서화합니다.

예시 일정

다음은 에디션 마감 일정의 예시입니다.

릴리스를 기준으로 한 마일스톤으로 표시되어 있습니다. 이전 에디션 릴리스는 연말(10월)에 stable에 도달했지만, 향후 에디션은 6월처럼 연중 더 이른 시기에 릴리스할 것을 적극 권장합니다.

이 날짜들은 확정된 것이 아니며(예를 들어 Rust는 6주 주기로 릴리스되므로 정확한 릴리스 날짜가 조금씩 달라집니다), 에디션 프로젝트 그룹이 필요에 따라 조정해야 합니다.

에디션 릴리스 날짜 1~3년 전
- 각 팀은 에디션 변경 사항을 계획하고 구현해야 합니다.
T-11개월
- 리더십 위원회는 에디션 프로젝트 그룹이 구성되어 준비를 마쳤는지 확인합니다.
- 에디션 일정을 발표하는 블로그 게시물을 작성합니다.
- 에디션 프로젝트 그룹은 각 팀과 변경 사항 목록을 조율하기 시작하고, 변경 사항을 추적할 추적 도구를 마련해야 합니다.
- 도구는 다음 에디션을 예비로 지원해야 합니다(이전 에디션 직후에 이 작업을 하는 것이 이상적입니다).
- 최종 기능 목록을 요청하고 최종 마감일을 알리는 공개 블로그 게시물을 작성합니다. 예시
T-10개월
- Pre-RFC 제안을 제출할 마지막 기회입니다.
T-9개월
- RFC를 승인받을 마지막 기회입니다.
T-8개월
- 에디션 변경 사항의 최종 목록이 확정되고 모든 RFC가 승인됩니다.
- 에디션에 포함되는 내용을 알리는 공개 블로그 게시물을 작성합니다. 예시
T-7개월
T-6개월
T-5개월
- 모든 기능과 마이그레이션이 nightly에 구현됩니다. 모든 기능 게이트를 제거해야 합니다.
T-4개월
- 모든 마이그레이션을 Crater로 테스트합니다(아래 Crater 마이그레이션 테스트를 참조하십시오).
- 에디션 프로젝트 그룹은 모든 에디션 이슈를 추적하여 제때 해결되도록 해야 합니다.
T-3개월
- nightly에서 최종 테스트를 요청하는 공개 블로그 게시물을 작성합니다. 예시
T-2개월
- 대부분의 이슈가 해결된 상태입니다.
- 문서화를 마칩니다(에디션 가이드, 레퍼런스 등).
- 에디션 프로젝트 그룹은 에디션을 안정화할지, 아니면 다음 릴리스로 연기해야 할지 최종 진행 여부를 결정해야 합니다.
- 모든 도구(rustc, cargo 등)의 nightly에서 에디션이 안정화됩니다.
T-1개월
- 에디션이 beta에 도달하며, 백포트할 수 있는 마지막 기회입니다.
- 릴리스 팀과 협력하여 릴리스 공지를 준비합니다. 예시
T-0개월
- 에디션이 stable로 릴리스됩니다.

Crater 마이그레이션 테스트

Crater는 마이그레이션 린트 테스트를 직접 지원하지 않습니다. crater 실행을 수행하려면 크레이트 마이그레이션에 필요한 단계를 수행하도록 수정된 버전의 cargo를 사용해야 합니다. #87190에 그 예시가 있습니다. 이는 대략 다음 단계를 수행합니다.

Crater 실행은 이전 메인 브랜치 빌드를 사용하여 cargo check를 실행합니다.
Crater 실행은 수정된 cargo를 사용하여 cargo check를 실행합니다. 이 수정된 cargo check는 일반적인 검사 대신 다음 단계를 수행합니다.
패키지를 임시 디렉터리로 복사합니다(crater에서는 소스 디렉터리가 읽기 전용이기 때문입니다).
패키지의 에디션이 현재 에디션보다 오래되었는지 확인합니다. 그렇다면 해당 패키지를 건너뜁니다. 현재 에디션으로의 마이그레이션만 테스트하려는 것이기 때문입니다.
cargo fix --edition --allow-no-vcs --allow-dirty를 실행합니다.
새 에디션을 설정하도록 Cargo.toml을 수정합니다.
실제 cargo check가 실행될 수 있도록 특수 환경 변수를 설정하여 cargo check를 실행합니다.

수정된 cargo는 cargo-features를 사용하지 않고도 새 에디션을 설정할 수 있게 해 줍니다.

마지막 cargo fix 또는 cargo check 단계가 실패했는데 이전 메인 브랜치 빌드에서는 검사가 성공했다면, 이는 마이그레이션이 실패한 회귀임을 나타냅니다.

그런 다음 에디션 프로젝트 그룹이 보고서를 분석하고, 문제가 있으면 이슈를 등록하며, 문제가 수정되도록 각 팀과 후속 조치를 진행할 책임을 집니다.

문제가 수정되면 다시 테스트해야 하므로 이 과정을 여러 번 반복해야 할 수도 있습니다.

에디션에 포함된 변경 사항이 얼마나 많은지에 따라 이를 실행하고 보고서를 분석하는 과정이 오래 걸릴 수 있다는 점에 유의하십시오. 2021 에디션은 약 한 달이 걸렸으며, 여기에는 수백 건의 회귀를 분석하고, 근본 원인을 파악하고, 수정 사항이 구현된 후 crater를 다시 실행하는 작업이 포함되었습니다.

에디션 안정화하기

에디션 팀이 안정화를 승인하면 실제 안정화 작업은 누구나 수행할 수 있습니다. 에디션을 안정화하려면 컴파일러, 문서, 모든 도구를 업데이트해야 합니다.

rustc에서 안정화합니다. rustc 안정화 지침을 참고하십시오.
cargo에서 안정화합니다(rustc 업데이트가 nightly에 반영된 후). cargo 안정화 지침을 참고하십시오.
- cargo 서브모듈을 업데이트합니다.
에디션 가이드를 업데이트하여 안정화되었음을 표시합니다. Rust 2024의 예시입니다.
대기 중인 모든 에디션 PR을 레퍼런스에 병합하고, 새로 안정화된 에디션을 기본값으로 사용하도록 레퍼런스를 업데이트하십시오(Rust 2024 예시).
모든 책 서브모듈을 업데이트합니다.
새 에디션을 제대로 지원하는 mdbook의 새 버전을 게시합니다. Rust 2024의 예시입니다.

블로그 게시물 및 공지

에디션 프로젝트 그룹과 관련 팀은 모든 사람과 일찍부터 자주 소통할 것을 강력히 권장합니다. 주요 마일스톤은 Rust 블로그에 공지해야 합니다. 전체 진행 상황과 일정에 관한 최신 소식을 담은 Inside Rust 블로그 게시물을 정기적으로(예: 매월) 작성해야 합니다.

적어도 공개 메시지에서는, 이상적으로는 모든 곳에서 에디션이 무엇이며 어떻게 동작하는지(코드가 깨지지 않습니다! 생태계가 분열되지 않습니다!) 거듭 설명하십시오. 혼란은 항상 생깁니다. 제 기억이 맞다면, 지난번에는 몇몇 기자가 사실을 확인하려고 Rust 재단에 연락하기도 했습니다. 재단 팀도 질문을 받게 될 것이므로, 에디션 프로젝트 그룹은 공개 메시지와 관련하여 재단 팀과 조율해야 합니다.

추적 도구

에디션 프로젝트 그룹은 에디션의 진행 상황을 추적하는 데 어떤 도구를 사용할지 결정해야 합니다. 개별 팀도 각자에게 가장 적합한 도구를 선택하고 싶어 할 것입니다. 과거에는 GitHub 프로젝트, GitHub 이슈 레이블, Google Sheets, HackMd 등 여러 도구를 함께 사용했습니다. 편한 도구를 사용하되, 공개적으로 접근할 수 있어야 한다는 점을 유념하십시오.

예시:

개별 팀의 추적 예시:

구현 참고 사항

개별 팀과 프로젝트에는 에디션 변경 사항을 구현하는 방법에 관한 각자의 자료가 있습니다. 에디션 변경 사항이 어떻게 구현되는지 알아보려는 경우 참고할 만한 추가 정보 링크는 다음과 같습니다.

기반 시스템이 어떻게 동작하는지 다시 살펴보려면 마이그레이션 동작 방식을 참고하십시오.
rustc-dev-guide에는 rustc에서 에디션별 변경 사항을 구현하는 방법에 관한 정보를 담은 에디션 장이 있습니다.
Rust 스타일 가이드에는 에디션별 스타일 변경 사항을 정의하는 Rust 스타일 에디션에 관한 정보가 있습니다.

역사적 배경

RFC 2052는 에디션 체계를 도입했으며 2018 에디션의 시작을 알렸습니다.
RFC 3085는 2021 에디션의 계획을 수립했으며, 에디션의 의미를 명확히 하고 변경했습니다.
RFC 3501은 2024 에디션의 시작을 알렸으며, 3년 주기를 공식화하고 향후 에디션을 관리하는 절차를 확립했습니다.

Keyboard shortcuts

Rust Forge