Sürümleme Politikası

React anlamsal sürümleme (semver) prensiplerini uygulamaktadır.

Bu demektir ki sürüm numarası x.y.z ile:

• Kritik hata düzeltmelerini yayınlarken z değerini güncelleyerek yama sürümünü yayınlarız (Örneğin: 15.6.2’den 15.6.3’a geçiş).
• Yeni özellikleri ya da kritik olmayan hata düzeltmelerini yayınlarken y değerini güncelleyerek minör sürümü yayınlarız (Örneğin: 15.6.2’den 15.7.0’a geçiş).
• Uyumsuz değişiklikleri yayınlarken x değerini güncelleyerek ana sürümü yayınlarız (Örneğin: 15.6.2’den 16.0.0’a geçiş).

Ana sürümler de yeni özellikler içerebilir, ve herhangi bir yeni sürüm hata düzeltmelerini bulundurabilir.

Minör sürümler en yaygın sürüm türüdür.

Uyumsuz Değişiklikler

Bu sürümleme politikası Next ve Experimental kanallarındaki sürüm-öncesi paketlerine uygulanmaz. Sürüm-öncesi paketlere dair daha fazlasını öğrenin.

Uyumsuz değişiklikler hepimiz için zahmetli olduğu için ana sürümlerin sayısını olabildiğince az tutmaya çalışıyoruz – örneğin, React 15 Nisan 2016’da, React 16 Eylül 2017’de, React 17 ise Ekim 2020’de yayınlanmıştır.

Bunun yerine yeni özellikleri minör sürümlerle yayınlamaktayız. Bu nedenle minör sürümler çoğu zaman ana sürümlerden daha ilgi çekici ve merak uyandırıcı olmaktadır.

Kararlılığa Bağlılık

React’ı zaman içinde değiştirdikçe React’ın yeni özelliklerindan faydalanmak için gereken çabayı azaltmaya özen göstermekteyiz. Bir önceki APIyi başka pakete koymamız gerekse bile, eski APIyi olabildiğince çalışır durumda tutarız. Örneğin, mixinlerin kullanımı yıllardır tavsiye edilmese bile, mixinler bu zamana kadar create-react-class ile desteklenmiştir ve birçok proje mixinleri eski kodlarında stabil şekilde kullanmaya devam etmektedir.

React kullanan bir milyondan fazla geliştirici, milyonlarca React bileşenini devam ettirmektedir. Sadece Facebook’un kodunda 50.000’den fazla React bileşeni vardır. Bu nedenle React versiyon yükseltemelerini olabildiğince kolay hale getirmemiz gerekmektedir; eğer büyük değişikler yapar ve buna geçiş için bir yol haritası sunmazsak, geliştiriciler eski sürümlerde takılı kalırlar. Geçiş için sunduğumuz çözümleri Facebook’ta kendimiz de test etmekteyiz - eğer 10 kişiden az olan takımımız, 50.000’den fazla bileşeni güncelleyebiliyorsa, React kullanan herkesin bu geçişi kolaylıkla yapabileceğine inanıyoruz. Çoğu zaman otomatikleştirilmiş scriptlerle bileşenleri güncelliyoruz, ve sonrasında bunları herkesin kullanması için açık kaynak sürümümüze dahil ediyoruz.

Uyarılarla Kademeli Versiyon Geçişi

React’ın geliştirme derlemeleri birçok yararlı uyarı içerir. Uyumsuz değişikliklere hazırlık için olabildiğince uyarı eklemekteyiz. Bu sayede, eğer uygulamanız son sürümde herhangi bir uyarı içermiyorsa, sonraki ana sürüme uyumlu olacaktır. Bu size uygulamalarınızdaki bileşenleri teker teker yeni sürüme geçirme olanağı sağlar.

Geliştirme uyarıları uygulamanızın işleyişini değiştirmez. Bu sayede uygulamanızın geliştirme ve canlı ortam derlemelerinde aynı şekilde davranacağına emin olabilirsiniz; aradaki tek fark canlı ortam derlemesinin uyarıları loglamayacak olmasıdır, ki bu daha verimlidir. (Eğer aksini farkederseniz, lütfen sorunu paylaşın)

Neler Uyumsuz Değişikliklerdir?

Aşağıdaki durumlarda genellikle ana versiyon yükseltmesi yapmıyoruz:

• Geliştirme uyarıları. Bunlar canlı ortamın davranışını etkilemediği için yeni uyarıları ekleyebilir, ya da varolanları değiştirebiliriz. Bu aslında gelecek uyumsuz değişikliklere karşı geliştiricileri güvenilir biçimde uyarmamızı sağlamaktadır.
• unstable_ ile başlayan APIler. Bunlar APIlerinden henüz emin olunmayan deneysel özelliklerdir. Bunları unstable_ ile başlayacak şekilde yayınlayarak daha hızlı ilerleyebilmekte ve stabil APIyi daha önce sunabilmekteyiz.
• React’ın alfa ve kanarya sürümleri. Yeni özelliklerin daha önce test edilebilmesi için alfa sürümlerini sunmaktayız, fakat alfa sürümünden öğrendiklerimizle de değişiklik yapma esnekliğine ihtiyaç duyuyoruz. Bu versiyonları kullanıyorsanız, APIlerin stabil sürümden önce değişebileceği ihtimalini unutmayın.
• Dökümente edilmemiş APIler ve içsel veri yapıları. Eğer __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ya da __reactInternalInstance$uk43rzhitjg, gibi dahili özellik isimlerine erişim sağladığınızda hiçbir güvence yoktur. Bu noktada artık kendi başınızasınız.

Bu prensipler faydacı yaklaşımla tasarlanmıştır; kesinlikle sizler için baş ağrısına sebep olmak istemiyoruz. Eğer bütün bu değişiklerle ana versiyon çıkarsak, daha fazla sayıda ana versiyon çıkmış oluruz ve bu topluluğa daha fazla versiyon çilesi yaratır. Ayrıca bu durum React’ı geliştirmek ve ilerletmek için istediğimiz kadar hızlı olamayacağımız anlamına da gelir.

Bununla beraber, eğer bu listedeki bir değişikliğin toplulukta fazlaca sorun yaratacağını düşünüyorsak, kademeli geçişte yol haritası sunmak için elimizden gelenin en iyisini yapmaya özen gösteriyoruz.

Bir minör sürüm yeni özellikler içermediği halde, neden bir yama sürümü değildir?

It’s possible that a minor release will not include new features. This is allowed by semver, which states ”[a minor version] MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes.”

However, it does raise the question of why these releases aren’t versioned as patches instead.

The answer is that any change to React (or other software) carries some risk of breaking in unexpected ways. Imagine a scenario where a patch release that fixes one bug accidentally introduces a different bug. This would not only be disruptive to developers, but also harm their confidence in future patch releases. It’s especially regrettable if the original fix is for a bug that is rarely encountered in practice.

We have a pretty good track record for keeping React releases free of bugs, but patch releases have an even higher bar for reliability because most developers assume they can be adopted without adverse consequences.

For these reasons, we reserve patch releases only for the most critical bugs and security vulnerabilities.

If a release includes non-essential changes — such as internal refactors, changes to implementation details, performance improvements, or minor bugfixes — we will bump the minor version even when there are no new features.