백포트

때때로 심각한 회귀를 수정하거나, 처음 병합될 당시에는 발견되지 못했던 의도치 않은 변경을 되돌리기 위해 컴파일러 수정 사항을 stable 및/또는 beta 채널로 백포트해야 하는 경우가 있습니다. 이슈와 회귀의 우선순위가 어떻게 정해지는지는 우선순위 지정을 참고하십시오.

stable 채널에 백포트가 적용되는 경우, Rust 프로젝트는 패치 릴리스를 배포합니다(예를 들어 최초의 stable 릴리스 1.87.0에 이어 1.87.1 포인트 릴리스가 나올 수 있습니다).

백포트 검토 지명하기

GitHub 풀 리퀘스트에 레이블을 붙여 어떤 변경 사항을 백포트하도록 제안할 수 있습니다. 패치를 beta 채널로 백포트해야 한다면 beta-nominated를 추가하고, stable 채널로도 백포트해야 한다면 stable-nominated도 함께 추가하십시오. 풀 리퀘스트에 T-compiler 레이블도 반드시 있는지 확인하십시오.

어떤 경우든, 풀 리퀘스트를 백포트로 지명할 때는 왜 백포트되어야 하는지에 대한 맥락을 컴파일러 팀 백포트 검토자에게 제공하는 댓글을 반드시 남겨야 합니다.

백포트 지명이 받아들여진다는 보장은 없습니다. 백포트 지명이 받아들여지거나 거부될 수 있는 기준에 대해서는 아래의 백포트를 승인해야 하는가 절을 참고하십시오.

stable 채널로 흘러간 beta 회귀는 stable 백포트 상정(그리고 승인될 경우 후속 패치 릴리스)이 필요합니다.

컴파일러 팀은 (P-critical로 레이블된) 심각한 이슈가 stable 릴리스로 진행되지 않도록 노력합니다.

컴파일러 백포트 지명 검토하기

beta-nominated 또는 stable-nominated 레이블 중 하나가 적용되면, Zulip의 #t-compiler/backports 채널에 새 스레드가 자동으로 열립니다. 컴파일러 팀 구성원은 이러한 Zulip 스레드를 이용해 비동기적으로 찬성 투표를 하거나 백포트에 대한 우려를 제기할 수 있습니다. 컴파일러 팀 구성원이며 이러한 스레드에 대한 알림을 받고 싶다면, 해당 Zulip 채널을 구독해야 합니다.

주간 트리아지 회의(#t-compiler/meetings에서 진행되며, 여기 참조) 동안 컴파일러 팀은 결정을 확정하고 해당하는 {beta,stable}-accepted 레이블을 적용합니다.

백포트를 승인해야 하는가?

컴파일러 백포트 검토자를 위해, 백포트 결정을 내릴 때 고려할 수 있는 비완전한 몇 가지 고려 사항은 다음과 같습니다:

• 지명된 변경 사항이 (예를 들어 구현 문제로 인해) stable 또는 beta 릴리스 채널에 시간 내에 병합되지 못한 경우.
• 백포트가 테스트될 시간이 충분한가?
  • (beta 백포트 지명의 경우) 지명된 변경 사항이 다음 stable 컴파일러 릴리스와 너무 가까운 시점에 적용될 경우. 이 시점에 백포트를 병합하면 테스트할 시간이 매우 제한적이게(있다 하더라도) 됩니다.
  • stable 포인트 릴리스는 숙성될 시간 없이 모든 사용자에게 즉시 제공됩니다!
• 지명된 컴파일러 변경 사항은 얼마나 복잡하거나 위험한가? 백포트가 새로운 회귀를 유발할 위험이, 해당 백포트가 해결하려는 회귀나 이슈보다 잠재적으로 더 나쁠 수 있습니까?
• 수정 중인 회귀/이슈는 얼마나 심각합니까?
  • 예를 들어 stable 회귀가 모두 동일한 것은 아닙니다. 일부는 그리 심각하지 않거나 이미 여러 릴리스에 걸쳐 stable 채널에 존재해 온 경우도 있습니다.

기본적으로 승인된 stable 백포트는 릴리스 팀이 새로운 포인트 릴리스를 발행하도록 합니다.

그러나 컴파일러 팀은 stable 백포트를 승인하면서도, 릴리스 팀에 해당 상정이 그 자체만으로는 stable 포인트 릴리스를 정당화하지 못한다고 추가로 알릴 수 있습니다. 이 경우 릴리스 팀은 승인된 다른 stable 백포트 후보들과 이 후보를 함께 고려하여 그 심각성을 판단하고, stable 포인트 릴리스를 실행할지 여부에 대한 결정을 확정합니다.

승인된 백포트는 어떻게 처리됩니까?

릴리스 팀(T-release)은 현재 개발 주기가 끝날 때 백포트를 처리합니다(릴리스 백포트 참조). beta 백포트 상정이 너무 늦게 승인될 경우, 릴리스 팀이 해당 변경 사항을 백포트하지 못할 수 있습니다.

대부분의 경우 승인된 백포트는 기본 브랜치를 대상으로 합니다. 드문 경우 beta 백포트가 beta 브랜치를 직접 대상으로 해야 할 수도 있습니다. 이 경우, 병합 전에 Zulip #t-release 채널에 새 스레드를 열어 릴리스 팀과 조율하십시오.

복잡한 백포트의 경우, 릴리스 팀이 패치 작성자에게 도움을 요청할 수 있습니다.