Release cycle ko KR

릴리스 주기

ASF는 A.B.C.D로 표기되는, 4개의 숫자로 구성된 일반적인 C# 버전 관리 방식을 사용합니다. 각 버전은 항상 고정되어 있으며, 빌드된 시점의 고정된 소스 코드를 가리킵니다(릴리스와 함께 번들로 제공됩니다). 저희 호스팅 제공업체(GitHub)가 이를 무기한 보존해주는 한, 이전에 게시된 어떤 버전도 제거할 계획이 없습니다. 따라서 별도로 백업하지 않아도 언제든 안전하게 이전 버전으로 롤백할 수 있습니다.

일반적으로 ASF 버전 관리에 있어, 저희는 최하위 3개 숫자, 즉 B.C.D에 대해 MAJOR.MINOR.PATCH 형식의 semver 버전 관리 방식을 최대한 따르려 하고 있습니다. 이 세 숫자는 ASF의 코드와 직접적으로 관련되어 있습니다. 가장 상위 숫자인 A는 보통 ASF 코드베이스 자체를 넘어서는 범위의 변경 사항을 나타내며, 매우 흔히 프로그램의 기반 자체에 영향을 미치는 변경입니다.

ASF 프로젝트는 대략 월 1회 기능 릴리스를 목표로 하며, 이는 C 숫자의 증가로 표시됩니다. 이러한 릴리스를 가능하게 하기 위해, 고급 사용자를 위한 더 작은 단위의 **프리릴리스(pre-release)**가 있습니다. 이는 마지막 프리릴리스 이후 다룰 만큼 충분한 변경 사항이 쌓였을 때 필요에 따라 배포되는, 변경 사항의 작은 이정표 역할을 합니다. 결국 최종 프리릴리스가 이전 안정 버전 대비 수정이 필요한 알려진 치명적 회귀(regression)가 없을 만큼 충분히 안정적이고 성숙했다고 판단되면, 이는 새로운 안정 버전으로 승격되며, 동시에 다음 릴리스를 위한 새로운 월간 주기가 시작됩니다.

저희 프리릴리스도 비교적 안정적으로 유지하기 위해 최선을 다하고 있지만, 프리릴리스는 프로덕션 환경에서 실행할 경우 신중하게 검토해야 한다는 점을 유의해야 합니다. 프리릴리스에는 치명적인 버그나 그 밖의 손상된 기능이 있을 수 있습니다. 이것이 바로 저희가 애초에 프리릴리스를 배포하는 이유이며, 이를 통해 안정 빌드에서는 이러한 문제들을 피하고 신뢰할 수 있는 소프트웨어를 제공할 수 있습니다.

불안정할 수 있는 소프트웨어를 사용함으로써 발생하는 위험 증가를 받아들이고 싶지 않으시다면, 프리릴리스 빌드 사용을 피하시고, 대다수 사용자에게 더 적합한 최신 안정(latest stable) 빌드를 사용하시기 바랍니다.

반대로 스스로를 고급 사용자로 여기시고 모두에게 배포되기 전에 새 릴리스 테스트를 돕고 싶으시다면, 언제든 환영입니다. 특히 현재 안정 버전에는 존재하지 않는 버그와 문제에 대한 피드백을 자유롭게 제공해 주세요.

주기 내 변경 사항의 양에 따라, 일반적으로 (이전 안정 버전 대비) C 버전이 한 번 증가하고, 각 프리릴리스마다 필요에 따라 D 버전이 증가합니다. 다만 특히 호환성이 깨지는(breaking) 변경과 같이 훨씬 더 큰 범위의 변경 사항을 도입하는 경우, 주기가 B 증가로 시작되거나(또는 도중에 전환되거나) 심지어 A 증가로 시작될 수도 있습니다. 이러한 전환은 현재 릴리스 주기가 평소보다 불안정할 가능성이 있으므로 신중하게 테스트해야 한다는 신호입니다.

semver 변경은 오직 이전에 게시된 안정 버전과의 관계에서만 적용된다는 점을 유념하세요. 즉, 프리릴리스들 자체 사이에서는 버전 관리를 별도로 추적하지 않습니다. 다시 말해, 이전에 표시된 안정 버전이 1.0.0.X 계열인 한, 1.0.1.2 버전에는 1.0.1.1에는 없던 새로운 기능이 포함될 수도 있습니다. 마찬가지로, 동일한 주기 내 두 프리릴리스 사이에도 큰 호환성 파괴 변경이 있을 수 있습니다. 이는 특히 새로 도입된 기능의 최종 형태를 아직 결정하는 중일 때 더욱 그렇습니다.

버전 증가(Version bump)	Semver	변경 사항 예시
A		주요 .NET 런타임 변경, 기반(foundation) 변경, ASF 코드베이스를 넘어서는 호환성 파괴 변경, 여러분의 고양이를 먹어치울 수도 있는 수준의 변경
B	Major	사소하지 않은 .NET 런타임 변경, ASF 코드베이스 내 호환성 파괴 변경, minor 분류를 넘어서는 주요 코드 수정
C	Minor	새로운 월간 주기, 일반적으로 기존 설정을 손상시키지 않는 새로운 기능, 명령어, 설정 속성 또는 그 밖의 변경 사항 도입
D	Patch	(더 상위 숫자로 표시되는) 기존 주기에 속한 새 프리릴리스, 필요 이상의 코드 변경 없이 기존 안정 버전에 대한 치명적 버그 수정

새로 도입되는 기능과 변경은 시간이 지난 후에도 위키 등에 문서화되지 않을 수도 있음을 양지하십시오. 작업중인 기능을 수정하기로 결정할 때마다 문서를 다시 작성하는 시간을 절약하기 위해 문서는 해당 기능의 최종 코드가 준비된 후에 작성됩니다. 프리릴리스에는 아직 최종 형태가 갖춰지지 않은 작업 중(work-in-progress) 코드가 포함될 수 있기 때문에, 문서화는 개발 후반 단계에 가서야 제공될 수 있습니다. 일반 변경사항도 동일하게 적용되어 사전 릴리스의 변경사항이 시간이 지난 후에도 없을 수 있습니다. 따라서 프리릴리스를 사용하기로 결정하셨다면, 때때로 ASF의 커밋 내역을 직접 살펴볼 준비를 하시기 바랍니다. 물론, 문서화 부족은 오직 프리릴리스에만 해당됩니다 - 각 안정 버전은 배포되는 즉시 항상 위키에 완전한 변경 로그(changelog)와 문서가 함께 제공되어야 합니다.

한 버전과 다른 버전을 비교하는 정확한 변경사항은 GitHub의 커밋과 코드 변경을 통해 항상 제공되고 있습니다. 릴리스할때, 마지막 안정 릴리스와 현재 릴리스간의 중요한 차이점만을 문서화하는 경향이 있습니다. 이러한 간략한 변경 로그는 결코 완전한 것이 아니므로, 한 버전과 다른 버전 사이에 발생한 모든 변경 사항(예: 저희의 종속성 업그레이드 등)을 확인하고 싶으시다면, GitHub 비교(comparison) 기능을 사용해 주세요.

ASF 프로젝트는 저희의 **지속적 통합(CI) 프로세스**로 운영됩니다. 모든 빌드는 재현 가능(reproducible)하도록 설계되어 있으므로, 특정 버전의 소스(릴리스에 포함되어 있음)를 가져와 직접 컴파일해도 미리 컴파일된 바이너리로 제공되는 것과 동일한 결과를 얻는 데 문제가 없습니다. 저희는 일반적으로 직접 컴파일하는 것을 피합니다. 시스템이 정상 작동하는 한, 배포되는 바이너리는 저희 CI 프로세스에서 직접 생성됩니다.