Add contents

Author: youngsunmin

content/docs/faq-versioning.md

@@ -10,12 +10,16 @@ React는 [시맨틱 버전 관리(semver)](https://semver.org/) 원칙을 따릅
 
 즉, 버전 번호는 **x.y.z**가 됩니다.
 
+* **크리티컬(critical) 버그를 수정**할 때는 **z** 번호를 바꾸고 **패치 릴리즈(patch release)** 를 합니다. (예를 들어, 15.6.2에서 15.6.3)
+* **새로운 기능**을 출시하거나 **크리티컬하지 않은(non-critical) 버그를 수정**할 때는 **y** 번호를 바꾸고 **마이너 릴리즈(minor release)** 를 합니다. (예를 들어, 15.6.2에서 15.7.0)
 * **대단위의 큰 변화**가 있을 때는 **x** 번호를 바꾸고 **메이저 릴리즈(major release)** 를 합니다.  (예를 들어, 15.6.2에서 16.0.0)
-* **새로운 기능**을 출시할 때는 **y** 번호를 바꾸고 **마이너 릴리즈(minor release)** 를 합니다. (예를 들어, 15.6.2에서 15.7.0)
-* **버그를 수정**할 때는 **z** 번호를 바꾸고 **패치 릴리즈(patch release)** 를 합니다. (예를 들어, 15.6.2에서 15.6.3)
 
 주요 릴리즈는 새 기능을 포함할 수도 있고 모든 릴리즈는 버그 수정을 포함할 수도 있습니다.
 
+마이너 릴리즈가 가장 보편적인 릴리즈 타입입니다.
+
+> 이 버전 관리 정책은 다음 또는 실험 채널의 시험판 빌드에는 적용되지 않습니다. [시험판에 대해서 더 알아보려면 여기를 보세요.](/docs/release-channels.html)
+
 ### 대단위의 큰 변화 {#breaking-changes}
 
 대단위의 큰 변화는 모든 사람에게 불편할 수 있습니다. 그래서 우리는 주요 릴리즈(major releases)는 최소화하도록 노력합니다. 예를 들어, React 15는 2016년 4월에 릴리즈되었고 React 16은 2017년 9월에 릴리즈되었습니다. 그리고 React 17은 2019년까지는 릴리즈되지 않을 것입니다.
@@ -36,7 +40,7 @@ React 개발 빌드는 상당수의 유용한 경고를 포함합니다. 가능
 
 ### 무엇을 대단위의 큰 변화로 볼 것인가? {#what-counts-as-a-breaking-change}
 
-보통 우리는 다음의 변경에는 메이저(major) 버전 번호를 *붙이지 않습니다*.  
+보통 우리는 다음의 변경에는 메이저(major) 버전 번호를 *붙이지 않습니다*.
 
 * **개발 시의 경고**. 프로덕션 빌드의 동작에는 영향을 미치지 않기 때문에 새 경고의 추가나 기존 경고의 수정은 주요 버전 사이에서 이행합니다. 이것으로 차기의 대단위 변경을 확실하게 경고할 수 있습니다. 
 * **`unstable_`로 시작하는 API**. 아직 신뢰할 수 있지는 않은 API를 사용한 실험적인 기능들에 제공합니다. `unstable_` 접두어를 사용한 버전을 릴리즈함으로써 개발주기를 조금 더 빠르게 하고 안정적인 API를 조금 더 빠르게 만들 수 있습니다.
@@ -46,3 +50,17 @@ React 개발 빌드는 상당수의 유용한 경고를 포함합니다. 가능
 여러분들이 두통을 유발하지 않도록 이 정책은 실용적으로 구성되어 있습니다. 만약 이 모든 변경에 대해 메이저 버전을 변경한다면 결국 더 많은 메이저 버전을 출시하게 될 것이고, 궁극적으로는 커뮤니티에 더 많은 버전닝 고통을 안기게 될 것입니다. 이것은 또한, 우리가 바라는 만큼 빠르게 React 향상을 진전시킬 수 없다는 것을 의미하기도 합니다. 
 
 그런데도 위의 목록과 같은 변경이 커뮤니티에서 광범위한 문제를 야기하게 된다면 점진적인 마이그레이션 수단(migration path)을 제공할 수 있도록 우리는 최선을 다할 것입니다.
+
+### 마이너 릴리즈에 포함할 새 기능이 없는 경우 왜 패치 버전 변경이 아닌 것일까요? {#minors-versus-patches}
+
+마이너 릴리즈에 새 기능이 포함되지 않을 수도 있습니다. [이것은 시맨틱 버전 관리에서 허용되는 범위](https://semver.org/#spec-item-7)로, **"[마이너 버전]은 개인 코드에 상당한 새 기능이나 개선이 도입되는 경우 증가할 수 있다. 패치 수준의 변경이 포함될 수 있다."** 라고 기재되어 있습니다.
+
+그렇지만, 왜 이런 릴리즈는 패치로 버전닝되지 않는지에 대한 의문이 제기됩니다.
+
+정답은 React(또는 다른 소프트웨어)의 어떤 변경은 뜻하지 않은 방법으로 침입할 위험이 있다는 것입니다. 하나의 버그를 수정하는 패치 릴리즈가 우연히 다른 버그를 양상하는 시나리오를 상상해 보세요. 이것은 개발자에게 차질을 일으킬 뿐 아니라 패치 릴리즈에 대한 개발자의 신뢰를 떨어뜨리기도 할 것입니다. 본래의 해결책이 사실상 거의 마주치지 않는 버그를 위한 것이라면 특히나 더 유감스러운 일입니다.
+
+우리는 React 릴리즈를 버그없이 지켜온 꽤 좋은 기록을 가지고 있습니다만, 대부분의 개발자들은 패치 릴리즈가 부정적인 결과없이 적용할 수 있다고 가정하기 때문에 패치 릴리즈는 신뢰성에 대한 훨씬 더 높은 기준을 가지고 있습니다.
+
+이런 이유로 우리는 가장 크리티컬한 버그와 보안 취약점에 대해서만 패치 릴리즈를 고수합니다.
+ 
+내부 리팩터, 구현 세부사항 변경, 성능 개성 또는 사소한 버그 수정과 같은 필수적이지 않은 변경이 포함된 릴리즈인 경우 새로운 기능이 없을 때라도 마이너 버전에 맞설 것입니다.