버전 정책
React는 유의적 버전 (semver) 원칙을 따릅니다.
즉, 버전 번호는 x.y.z 형태가 됩니다.
- 치명적인 버그를 수정할 때는 z 번호를 바꾸고 수 버전을 올려 배포합니다. (예를 들어, 15.6.2에서 15.6.3)
- 새로운 기능을 출시하거나 치명적이지 않은 버그를 수정할 때는 y 번호를 바꾸고 부 버전을 올려 배포를 합니다. (예를 들어, 15.6.2에서 15.7.0)
- 호환성이 유지되지 않는 변경이 있을 때는 x 번호를 바꾸고 주 버전을 올려 배포를 합니다. (예를 들어, 15.6.2에서 16.0.0)
주 버전 배포는 새 기능을 포함할 수 있으며 모든 배포에는 버그 수정을 포함할 수도 있습니다.
부 버전을 변경시킨 배포가 가장 보편적인 배포 형태입니다.
해당 버전 정책은 Next 또는 Experimental 채널의 prerelease 빌드에는 적용되지 않습니다. prerelease에 대해 여기서 알아보세요.
호환성이 유지되지 않는 변경
<<<<<<< HEAD 호환성이 유지되지 않는 변경은 모든 사람에게 불편할 수 있습니다. 그래서 주 버전 배포는 최소화하도록 노력합니다. 예를 들어, React 15는 2016년 4월에 배포되었고 React 16은 2017년 9월에 배포되었습니다. 그리고 React 17은 2020년에 가능할 수도 있습니다. ======= Breaking changes are inconvenient for everyone, so we try to minimize the number of major releases – for example, React 15 was released in April 2016 and React 16 was released in September 2017, and React 17 was released in October 2020.
4fc709d0576d0f0f1f8ea8b6bb341a12944b5510
대신 부 버전을 변경시킨 배포로 새 기능을 배포합니다. 부 버전 배포는 겸손한 이름에도 불구하고, 주 버전 배포보다 가끔 더 흥미롭고 주목할 만합니다.
안정성을 위한 노력
React가 서서히 변화하는 가운데 우리는 새 기능을 도입하기 위해 필요한 노력은 최소화하고 있습니다. 오래된 API를 다른 패키지로 분리하더라도, 오래된 API가 계속 동작하도록 가능한 유지할 예정입니다. 예를 들어, 믹스인은 수년 동안 그 기세가 꺾여오고 있지만, create-react-class를 통해서 오늘날까지 지원되고 있고, 많은 코드 베이스가 안정된 레거시 코드에서 오래된 API를 계속 사용되고 있습니다.
백만 명 이상의 개발자가 React를 사용하고 있고, React에는 통틀어 수백만 개의 컴포넌트가 유지되고 있습니다. 페이스북 코드 베이스만 고려해 봐도 50,000개 이상의 React 컴포넌트가 있습니다. 이것은 React의 새 버전으로의 업그레이드를 가능한 한 쉽게 만들 필요가 있음을 의미합니다. 마이그레이션 수단도 없이 대단위의 큰 변화가 발생한다면 개발자들은 구버전에 갇히게 될 것입니다. 우리는 이 업그레이드 방법을 페이스북 자체에 테스트하고 있습니다. 열 명도 되지 않는 우리 팀이 단독적으로 5만 개 이상의 컴포넌트를 업데이트할 수 있다면 React를 사용하는 모든 개발자가 업그레이드를 관리할 수 있기를 기대합니다. 대부분의 경우, 컴포넌트 구문을 업그레이드하기 위한 자동화 스크립트를 오픈소스 배포에 포함해서 누구나 사용할 수 있도록 하고 있습니다.
경고를 통한 점진적인 업그레이드
React 개발 빌드는 상당수의 유용한 경고를 포함합니다. 가능한 한 미래의 큰 변화에 대비하여 경고를 추가합니다. 최신 배포에서 여러분의 앱이 경고를 표시하지 않았다면 다음에 배포될 주 버전과 호환될 겁니다. 경고 덕분에 여러분은 컴포넌트 하나씩 앱을 업그레이드할 수 있게 해줍니다.
개발 경고는 앱의 런타임 수행에 영향을 주지는 않습니다. 다만, 그로 인해 앱의 개발 빌드와 프로덕션 빌드가 동일한 방식으로 동작할 거라는 확신을 가질 수 있습니다. 개발 빌드와 유일한 차이점이라면 프로덕션 빌드는 경고를 출력하지 않으며 조금 더 효율적입니다. (또 다른 점이 발견된다면 이슈를 제출해주세요)
무엇이 호환되지 않는 변화일까요?
보통 우리는 다음의 변경에는 주 버전 번호를 변화시키지 않습니다.
- 개발 환경에서의 경고. 프로덕션 빌드의 동작에는 영향을 미치지 않기 때문에 주요 버전 간에 새로운 경고를 추가하거나 기존 경고를 수정할 수 있습니다. 실제로, 이를 통해 다가올 호환되지 않는 변화에 대해 확실하게 경고할 수 있게 해줍니다.
unstable_로 시작하는 API. 아직 신뢰할 수 있지 않은 API를 실험적인 기능으로 제공합니다.unstable_접두어를 사용한 버전을 배포해서 개발 주기를 조금 더 빠르게 하고 안정적인 API를 조금 더 빠르게 얻을 수 있습니다.- React의 알파 버전과 카나리아(canary) 버전. 새 기능의 이른 테스트를 위한 방법으로 React의 알파 버전을 제공합니다. 그러나 동시에, 알파 기간에 습득한 것을 바탕으로 변경을 자유롭게 할 수 있는 유연함도 필요합니다. 알파 버전을 사용하고 있다면 안정 버전이 출시되기 전에는 API가 얼마든지 변경될 수 있으니 주의해주세요.
- 문서화되지 않은 API와 내부 데이터 구조.
__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED라든지__reactInternalInstance$uk43rzhitjg와 같은 내부 프로퍼티에 접근한다면 책임은 스스로 지셔야 합니다.
이 정책은 실용적으로 설계되었습니다. 특히, 여러분의 머리가 아프지 않았으면 합니다. 이 모든 변화에 대해 주 버전 번호를 변화시킨다면, 더 많은 주 버전을 배포하게 되고 결국 커뮤니티에 버전 관리에 대한 고통을 더 가져다줄 겁니다. 이것은 우리가 바라는 만큼 빠르게 React를 발전시킬 수 없다는 것을 의미하기도 합니다.
그런데도 위의 목록과 같은 변경이 커뮤니티에서 광범위한 문제를 일으키게 된다면 점진적으로 마이그레이션 할 수 있는 수단을 제공할 수 있도록 최선을 다할 것입니다.
부 버전 배포에 새로운 기능이 포함되어 있지 않다면, 왜 수 버전을 변경하지 않나요?
부 버전 배포에 새 기능이 포함되지 않을 수도 있습니다. 유의적 버전 관리에서 허용되며, ”[부 버전]은 개인 코드에 상당한 새 기능이나 개선이 도입되는 경우 증가할 수 있다. 수 버전 수준의 변경이 포함될 수 있다.”라고 기재되어 있습니다.
그렇지만, 이런 배포는 왜 수 버전으로 배포하지 않는지 의문을 제기합니다.
정답은 React (또는 다른 소프트웨어)의 변경은 예상하지 못한 방식으로 고장 낼 위험이 있습니다. 하나의 버그를 수정하는 수 버전 배포가 실수로 다른 버그를 만들어내는 시나리오를 상상해 보세요. 이것은 개발자에게 혼란을 줄 뿐만 아니라 수 버전 배포에 대한 개발자의 신뢰를 떨어뜨립니다. 특히 원래의 해결책이 거의 마주치지 않는 버그에 대한 수정이라면 더욱 유감스러운 일입니다.
우리는 React 배포를 버그 없이 지켜온 꽤 좋은 기록을 가지고 있지만, 대부분의 개발자는 수 버전 배포가 부정적인 결과 없이 적용할 수 있다고 가정하기 때문에 수 버전 배포는 안정성에 대한 기준이 훨씬 높습니다.
이런 이유로 가장 중요한 버그와 보안 취약점에 대해서만 수 버전 배포를 사용합니다.
내부 코드 리팩토링이나 구현 세부사항에 대한 변화, 성능 개선, 사소한 버그 수정처럼 핵심적이지 않은 변경이 포함된 배포라면, 새로운 기능이 없을 때라도 부 버전을 증가시킬 겁니다.