에디션 릴리스

이 문서는 에디션 릴리스를 관리하는 방법에 대한 개요를 제공합니다. 이 문서는 독자가 에디션이 무엇인지 이미 알고 있다고 가정합니다([에디션 가이드]를 참고하십시오).

에디션 프로젝트 그룹

RFC 3501은 리더십 위원회가 에디션 관리를 책임지는 프로젝트 그룹을 구성할 책임이 있다고 규정합니다.

프로젝트 그룹 리드

비교적 촉박한 일정 내에 필요한 조정과 신속한 결정 및 조치를 더 쉽게 하기 위해, 프로젝트 그룹은 2~3명의 리드를 두는 것이 권장됩니다.

또 다른 고려 사항은 헌신도와 시간적 여유입니다. 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는 이전 main 브랜치 빌드를 사용하여 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 단계가 실패하고 이전 main 브랜치 빌드에서는 검사가 성공했다면, 이는 마이그레이션이 실패한 회귀를 나타냅니다.

이후 에디션 프로젝트 그룹은 보고서를 분석하고, 문제에 대한 이슈를 등록하며, 해당 문제가 해결되도록 팀들과 후속 조치를 취할 책임이 있습니다.

이 과정은 문제가 수정되고 재테스트가 필요함에 따라 여러 번 반복해야 할 수도 있습니다.

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

에디션 안정화하기

에디션 팀이 안정화를 승인하면, 실제 안정화 작업은 누구든지 수행할 수 있습니다. 에디션을 안정화하는 작업에는 컴파일러, 문서, 그리고 모든 도구를 업데이트하는 것이 포함됩니다:

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

블로그 게시물 및 공지

에디션 프로젝트 그룹과 관련 팀들이 모든 사람과 조기에 자주 소통할 것을 강력히 권장합니다. 주요 마일스톤은 Rust 블로그에 발표해야 합니다. Inside Rust 블로그 게시물은 전반적인 진행 상황과 일정에 대한 업데이트와 함께 정기적으로(예: 매월) 작성되어야 합니다.

일부는 공개 메시지에서, 하지만 이상적으로는 모든 곳에서 에디션이 무엇이고 어떻게 동작하는지(코드가 깨지지 않습니다! 생태계가 분열되지 않습니다!)를 반복해서 강조하십시오. 항상 혼란이 있습니다. 제가 기억하기로 지난번에는 일부 기자들이 확인을 위해 Rust 재단에 연락한 적이 있습니다. 에디션 프로젝트 그룹은 재단 팀이 관련 질문을 받게 될 것이므로 공개 메시지 작성에 있어 재단 팀과 조율해야 합니다.

추적 도구

에디션 프로젝트 그룹은 에디션의 진행 상황을 추적하는 데 어떤 도구를 사용할지 결정해야 합니다. 개별 팀들 또한 자신들에게 가장 적합한 도구를 선택하고 싶어할 가능성이 큽니다. 과거에는 GitHub 프로젝트, GitHub 이슈 라벨, Google 스프레드시트, HackMd 등 다양한 도구를 혼용해 왔습니다. 편한 것을 사용하되, 공개적으로 접근 가능해야 한다는 점만 유념하십시오.

예시:

개별 팀 추적 예시:

구현 노트

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

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

역사적 맥락

RFC 2052는 에디션 시스템을 시작했으며, 2018 에디션의 시작을 알렸습니다.
RFC 3085는 2021 에디션의 계획을 세웠을 뿐만 아니라, 에디션의 의미를 명확히 하고 변경했습니다.
RFC 3501은 2024 에디션의 시작을 알렸을 뿐만 아니라, 3년 주기를 공식화하고 향후 에디션 관리를 위한 프로세스를 확립했습니다.

Keyboard shortcuts

Rust Forge