Linux cekirdek tarihcesi ve kritik karar surecleri

Linux çekirdek geçmişinin kısa özeti

Linux kernel geçmişi, Eylül 1991'deki 0.01 sürümünden günümüzde sunucularda başlatılan 7.x serisine kadar uzanır. Sürüm listesi, bu konunun en az ilgi çekici bölümüdür. Az sayıda karar, bu yapının biçimini belirledi. Bu kararların her birinin bugün kiralanan bir makinede hâlâ bir sonucu vardır. 1991'de neden yeni bir kernel gerektiği, Unix'in, AT&T lisanslamasının ve BSD'yi durduran davanın daha uzun hikâyesinin bir parçasıdır.

Buradaki tarihler ve sürüm numaraları kernel.org ve yayınladığı sürüm geçmişinden alınmıştır. Ağustos 2026 itibarıyla mevcut durum şöyledir: 7.0 sürümü 12 Nisan 2026'da, 7.1 sürümü 14 Haziran 2026'da yayınlanmıştır ve 7.2 sürümü şu an aday sürümler (release candidates) aşamasındadır.

1992 yılında yapılan GPL tercihinin güncel önemi

Sürüm 0.01, 17 Eylül 1991 tarihinde Torvalds'ın bizzat kaleme aldığı bir lisansla yayımlandı. Bu lisans, kaynak kodun dağıtılmasını zorunlu kılıyordu ve daha kritik bir ifade ekliyordu: "Bunu bir ücret karşılığında, 'işlem' masrafları dahil olmak üzere dağıtamazsınız." 1991 yılında yazılımlar disketlerle dağıtılıyordu ve disketlerin kopyalanıp postalanması maliyetli bir işlemdi. Bu madde, ticari bir Linux dağıtımını imkansız hale getiriyordu.

Torvalds bu durumu değiştirdi. GNU General Public License (GPL) lisansına geçiş, Ocak 1992'deki 0.12 sürüm notlarında duyuruldu ve 1 Şubat 1992 itibarıyla yürürlüğe girdi. Mart 1992'deki 0.95 sürümü, bu lisans altında yayımlanan ilk sürümdü. Daha sonra Linux üzerine inşa edilen tüm ticari yapılar, bu değişikliğe dayanmaktadır.

Çekirdek yalnızca GPL sürüm 2 lisansına sahiptir ve hiçbir zaman sürüm 3'e geçmemiştir. Torvalds 2007 yılında, büyük ölçüde GPLv3'teki "anti-tivoisation" kuralı nedeniyle bu geçişi reddetti. Söz konusu kural, GPL kodunu içeren bir cihazın, bu kodun değiştirilmiş bir kopyasını da kabul etmesini zorunlu kılıyordu. Torvalds, kilitli donanımları üreticinin kendi ticari meselesi olarak değerlendirdi. 2017 yılında çekirdek geliştiricileri, Kernel Enforcement Statement belgesini yayımladı. Bu belge, GPLv3'ten bir maddeyi ödünç almaktadır: Bir ihlali bildirimden sonra düzelten kişi, lisansını kalıcı olarak kaybetmek yerine lisans hakkını korumaya devam eder.

Bu durumun sunucu tarafında iki sonucu vardır. Önyüklediğiniz çekirdek ikili dosyası, ilgili kaynak koda erişim hakkını beraberinde getirir; dolayısıyla hiç kimse size inceleyemeyeceğiniz veya yeniden derleyemeyeceğiniz bir Linux çekirdeği veremez. Ayrıca çekirdek üzerindeki telif hakkı bildirimi, lisansın normal sistem çağrıları aracılığıyla çekirdek servislerini kullanan kullanıcı programlarını kapsamadığını belirtir. Bu sayede tescilli veritabanları ve izleme ajanları, herhangi bir kuralı ihlal etmeden Linux için dağıtılabilir. İzin verici (permissive) bir lisans ise tam tersi bir baskı oluşturur. Bir platform seçmeden önce bu farkı anlamak önemlidir: bkz. Sunucu platformları olarak Linux ve FreeBSD.

Monolitik çekirdek pratikte neden kazandı

29 Ocak 1992 tarihinde Andrew Tanenbaum, comp.os.minix haber grubuna "LINUX is obsolete" başlıklı bir ileti gönderdi. İki iddiada bulundu. Sürücülerin ve dosya sistemlerinin tek bir ayrıcalıklı adres alanı içinde çalıştığı monolitik çekirdeklerin 1970'lerin tasarımı olduğunu, bu parçaların sıradan süreçler olarak çalıştığı mikro çekirdeklerin ise geleceği temsil ettiğini savundu. Ayrıca Linux'un Intel 386 mimarisine sıkı sıkıya bağlı olduğunu ve bu yüzden asla başka platformlara taşınamayacağını öne sürdü.

Taşınabilirlik iddiası, sistemin farklı mimarilere taşınmasıyla çürütüldü. Mart 1995'teki 1.2 sürümü ile Alpha, SPARC ve MIPS desteği eklendi. Haziran 1996'daki 2.0 sürümü ise 64-bit Alpha portunu getirdi.

Tasarım iddiası ise bir uzlaşma ile yanıtlandı. Linux hiçbir zaman bir mikro çekirdek olmadı. Bunun yerine yüklenebilir çekirdek modülleri (loadable kernel modules) eklendi: çalışan bir çekirdeğe ekleyip çıkarabildiğiniz nesne dosyaları sayesinde, bir sürücü çekirdek ikili dosyasından ayrı olarak dağıtılabilir hale geldi.

lsmod | head
modinfo virtio_net | head -5

lsmod şu anda nelerin yüklü olduğunu listeler. modinfo ise modülün geldiği dosyayı ve kabul ettiği parametreleri yazdırır. Sanal bir sunucuda disk ve ağ yolunun büyük bir kısmı modüllerden oluşur; bu nedenle tek bir çekirdek imajı, daha önce hiç karşılaşmadığı donanımlarda bile önyüklenebilir. Çekirdek yalnızca yeni donanımı duyurur, kullanıcı alanı arka plan süreci (daemon) ise hangi modülün yükleneceğine ve cihaza ne ad verileceğine karar verir. Cihaz yönetiminin init sisteminin içine yerleşmesinin nedeni budur ve systemd'den kaçınmanın zorlaşmasının bir parçası da budur.

Modüller, mikro çekirdek tasarımının getirdiği maliyet olmadan bu esnekliği sağladı. Bir sürücüyü kendi süreci içinde izole etmek, her çağrıda bir bağlam değişimi (context switch) ve mesajlaşma maliyeti ödemek anlamına gelir; 1992 yılında bu maliyet oldukça yüksekti.

Linux'un koruduğu ve planlama gerektiren maliyet ise şudur: bir modül tam çekirdek ayrıcalıklarıyla çalışır, bu yüzden hatalı bir modül tek bir süreci değil, tüm makineyi çökertir. Bu durumun en çok hissedildiği yer, ana çekirdek ağacı dışında kalan (out-of-tree) modüllerdir. Ana çekirdekte yer almayan bir üretici sürücüsü, her yeni çekirdek sürümünde yeniden derlenmelidir; DKMS yükseltme sırasında tam olarak bunu yapar ve bu derleme başarısız olduğunda, yeniden başlatmanın ardından cihaz basitçe kullanılamaz hale gelir.

SMP'nin tamamlanması neden on beş yıl sürdü

Haziran 1996'da yayınlanan Linux 2.0, simetrik çoklu işlem (SMP) desteğine sahip ilk çekirdekti; bu, birden fazla CPU'nun tek bir çekirdeği çalıştırabileceği anlamına geliyordu. İlk uygulama, tek bir kilit olan büyük çekirdek kilidini (BKL) kullanıyordu, bu nedenle aynı anda yalnızca bir işlemci çekirdek kodu içinde bulunabiliyordu. Bu nedenle ikinci bir CPU, kullanıcı alanında hesaplama yapan bir iş yüküne yardımcı olurken, sistem çağrılarından oluşan bir iş yüküne çok az katkı sağlıyordu çünkü bu çağrılar aynı kilidin arkasında kuyruğa giriyordu.

Bu kilidin kaldırılması on beş yıl sürdü. Kalan kullanıcılar büyük ölçüde Arnd Bergmann tarafından ince taneli kilitleme yapısına dönüştürüldü ve BKL, 18 Mayıs 2011'de yayınlanan 2.6.39 sürümünde silindi. Zamanlayıcı da aynı yavaş zaman çizelgesinde ilerledi: 2.6.0 sürümündeki O(1) zamanlayıcı, 2007'de 2.6.23 ile gelen Completely Fair Scheduler (CFS) ve Ekim 2023'te 6.6 sürümünde CFS'nin yerini alan EEVDF.

Bu çalışmalar, 4 vCPU'lu bir planın günümüzde sıradan kabul edilmesinin nedenidir. Ayrıca bilinmesi gereken bir sınırı da işaret eder. Paylaşımlı bir sanal sunucuda çekirdeğiniz iş parçacıklarınızı zamanlar, hipervizör ise çekirdeğinizi zamanlar. top komutunu çalıştırın ve %st alanını okuyun. Steal time, çekirdeğinizin kullanmaya hazır olduğu ancak ana makinenin başka bir konuğa verdiği CPU süresidir; bu nedenle çekirdeğiniz içindeki hiçbir ayar bunu geri kazandıramaz.

2.6 serisinin çekirdek derleme yöntemini neden değiştirdiği

2.6 sürümünden önce sürüm numaraları çiftler halinde gelirdi. İkinci numaranın çift olması kararlı bir seriyi (2.4), tek olması ise geliştirme aşamasını (2.5) temsil ederdi. 2.4 sürümü 4 Ocak 2001'de, 2.6 ise 17 Aralık 2003'te yayınlandığından, kullanıcılar bir sonraki kararlı seri için yaklaşık üç yıl beklemek zorunda kaldı. Dağıtımlar bu kadar bekleyemediği için geriye dönük yamalar (backport) uyguladı. "2.4" sürümünü sunan iki farklı tedarikçi, aralarında binlerce yama farkı olan çekirdekler dağıtıyordu.

Bu ayrım 2.6 sürümünden sonra kaldırıldı. Ana hat (mainline) artık yaklaşık iki haftalık bir birleştirme penceresi açıyor, yeni çalışmaları kabul ediyor, ardından süreç sakinleşene kadar sürüm adayları (release candidates) yayınlıyor ve kernel.org'un hala belgelediği üzere her 9 ila 10 haftada bir yeni sürüm çıkarıyor. Modelin diğer yarısı ise 4 Mart 2005'te, Greg Kroah-Hartman ve Chris Wright tarafından sürdürülen 2.6.11 sürümüne yönelik yalnızca düzeltme içeren ilk kararlı ağaç güncellemesiyle hayata geçti. Kararlı ağaç yalnızca düzeltmeleri kabul eder ve yeni özellikleri reddeder.

Bunun bir yan etkisi olarak sürüm numarası bir vaat olmaktan çıktı. 3.0, 4.0, 5.0 ve 7.0 sürümleri yeniden yazılmış sürümler değildir. Torvalds, ikinci numara onu rahatsız edecek kadar büyüdüğünde ilk numarayı yükseltir; Nisan 2026'da 6.19 sürümünü 7.0'ın takip etmesinin nedeni budur. Bir sunucu için önemli olan, dağıtımınızın hangi dalı takip ettiği ve o dalın hala düzeltme alıp almadığıdır.

BitKeeper kopuşu Nisan 2005'te git'i nasıl ortaya çıkardı

Çekirdek geliştirme süreci, 2.5 serisinden itibaren Şubat 2002'den itibaren Larry McVoy'un şirketi BitMover'a ait tescilli bir dağıtık sürüm kontrol sistemi olan BitKeeper üzerinde yürütülüyordu. BitMover, çekirdek geliştiricilerine bazı koşullara bağlı ücretsiz bir lisans sağlamıştı: rakip bir sürüm kontrol aracı üzerinde çalışamazdınız ve BitKeeper'ı tersine mühendislik ile inceleyemezdiniz. Birçok geliştirici, içeriğini okumalarına izin verilmeyen bir araçla özgür bir çekirdek oluşturmaktan rahatsızdı.

Bu durum, Nisan 2005'te Andrew Tridgell'in BitKeeper depolarıyla iletişim kurabilen bir programı göstermesinin ardından bozuldu. BitMover bunu tersine mühendislik olarak nitelendirdi ve ücretsiz lisansı geri çekti. Çekirdek, bir geliştirme döngüsünün ortasında sürüm kontrol sistemini kaybetti.

git üzerindeki çalışmalar 3 Nisan 2005'te başladı. Torvalds, projeyi 6 Nisan'da duyurdu. 7 Nisan'da git kendi kendini barındırır (self-hosting) hale geldi; yani git'in kendi geçmişi zaten git içinde tutuluyordu. Birkaç dalın ilk birleştirme işlemi (merge) 18 Nisan'da gerçekleştirildi. Haziran 2005'te git, 2.6.12 sürümünün yayınlanmasını yönetti. Torvalds, kısa bir süre sonra bakım sorumluluğunu Junio Hamano'ya devretti ve çekirdek çalışmalarına geri döndü.

Tasarım doğrudan mevcut sorundan doğdu: binlerce katkıda bulunan kişi ve kimsenin güvenmediği bir ağ üzerinden birbirlerinden veri çeken (pull) bakımcılar. Her nesne, içeriğinin özeti (hash) ile adlandırılır; bu nedenle eski geçmişteki tek bir baytın değiştirilmesi, ondan sonra gelen her commit'in adını değiştirir. Bir klonun sadece bir iddia değil, kanıt olmasının nedeni budur. Her dağıtım hattı, her yapılandırma deposu, ekiplerin kod gönderdiği kod barındırma platformları ve kendi sunucunuzda çalıştırabileceğiniz git sunucusu, bir çekirdek lisanslama tartışmasından doğmuştur.

LTS modelinin vaat ettikleri ve etmedikleri

Mainline sürümü, üretim ortamında çalıştırılacak sürüm değildir. Bir mainline sürümü, 9 ila 10 hafta sonra yerini bir sonrakine bırakır. Stable ağacı, her sürümden sonra birkaç hafta boyunca düzeltmeleri barındırır. Genellikle LTS olarak adlandırılan Longterm dalları ise bu düzeltmeleri yıllarca taşır ve dağıtımlar bu dalları temel alır.

Aralık 2009'da yayınlanan 2.6.32, bu modelin kendini kanıtladığı sürümdür. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 ve Ubuntu 10.04 LTS'nin tamamı bu sürümü kullanmıştır. Bu dal, yayınlanmasından altı yıldan fazla bir süre sonra, Şubat 2016'ya kadar desteklenmiştir. Red Hat, RHEL 6'nın 2020'deki ömrünün sonuna kadar 2.6.32 tabanlı çekirdeğini kendi backport'ları ile destekleyerek bu süreyi daha da uzatmıştır. CentOS'un var olma nedeni ve Rocky Linux ile AlmaLinux'un onun yerini alması, bu on yıllık destek sürecini ücretsiz olarak yeniden üretme çabasına dayanır.

Bu vaat birden fazla kez değişmiştir. Başlangıçta iki yıl olan destek süresi, bazı dallar için altı yıla çıkmıştır. 2023 yılında stable sürüm sorumluları, eski ağaçlara backport yapmanın bakım süresini tüketmesi ve eski dalların gerçek anlamda çok az test edilmesi nedeniyle varsayılan süreyi iki yıla indirmiştir. 25 Şubat 2026 tarihinde Greg Kroah-Hartman, bu dallara bağımlı şirketlerle yapılan görüşmelerin ardından daha uzun projeksiyonlar yayınlamış ve mevcut çerçeve üç ila altı yıl arasına çekilmiştir.

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

kernel.org, Ağustos 2026 itibarıyla 6 adet longterm dalı listelemektedir. En eskisi olan 5.10, Dec 2026 tarihinde sona erdiğinde 6.0 yıl boyunca düzeltmeleri taşımış olacaktır. En yenisi olan 6.18 ise Dec 2028 tarihine kadar sürecek şekilde planlanmıştır ve bu da 3.1 yıllık düzeltme desteği anlamına gelir.

Bu tarihleri bir sözleşme olarak değil, bir alt sınır olarak değerlendirin. 6.6 ve 6.12 projeksiyonlarının her ikisi de Şubat 2026'da ileriye taşınmıştır; kimsenin kullanmadığı bir dal ise destekten kaldırılabilir. Dağıtımınız bu seçimi genellikle sizin yerinize yapar: Debian 13, 6.12 sürümünü; Ubuntu 26.04 LTS ise 7.0 sürümünü kullanır. Bu fark, sunucuda LTS ile ara sürüm seçimi sorusunun pratik karşılığıdır ve Ubuntu 24.04'ten 26.04'e yükseltme yaptığınızda altyapınızda gerçekten değişen şey budur.

Bu durumdan kaynaklanan bir tuzak mevcuttur. Ubuntu 24.04 üzerinde uname -r komutu, 6.8.0-51-generic gibi bir çıktı verir. Bu çıktı, upstream taban ile dağıtımın kendi backport'larının birleşimidir. Dolayısıyla bu numara, dalın nereden başladığını gösterir, içinde hangi düzeltmelerin olduğunu değil. Çekirdeği yalnızca sürüm dizgisine göre değerlendiren tarayıcılar, tam da bu nedenle dağıtım çekirdekleri hakkında hatalı alarmlar üretir.

Çekirdeğin şu anki tartışma konuları

İki tartışma devam etmektedir ve her ikisi de işi kimin yapacağı üzerinedir.

Rust, Aralık 2022'de 6.1 sürümüyle altyapı olarak çekirdeğe dahil edildi. 7.0 sürümünde deneysel etiketi kaldırıldı; böylece çekirdeğin temel dilleri C, assembly ve Rust haline geldi ve derleme süreci artık nightly derleyiciye ihtiyaç duymuyor. Tartışma, bakım sorumluluğu üzerinedir. Bir arayüzü değiştiren C bakımcısı, okumadığı Rust bağlamalarını bozabilir ve tartışma, bunları düzeltmenin kimin görevi olduğu üzerinedir.

İkinci tartışma ise yapay zeka katkılarıdır. Sasha Levin, makine destekli yamaların listelere ulaşan artan hacminin ardından Temmuz 2025'te bir politika önerdi. Belge 23 Aralık 2025 tarihinde işleme alındı ve şu anda çekirdeğin kendi süreç dokümantasyonunda docs.kernel.org/process/coding-assistants.html adresinde yer almaktadır. Bir yapay zeka temsilcisi Signed-off-by etiketi ekleyemez, çünkü bu satır Developer Certificate of Origin (DCO) belgesini onaylar ve bunu yalnızca bir kişi onaylayabilir. Yardım, inceleme sırasında Co-developed-by: etiketinden değiştirilen bir Assisted-by: etiketi ile beyan edilir; çünkü bir araç yazar değildir. Üretilen kod, yalnızca GPL-2.0 ile uyumlu olmalıdır. Yamayı gönderen insan, yamayı inceler ve sorumluluğunu üstlenir.

Politikanın arkasındaki baskı, inceleme süresidir. Bir yama oluşturmak saniyeler sürerken, bir tanesini incelemek bir bakımcının öğleden sonrasını almaktadır. Bir etiket bu dengesizliği düzeltmez. Koruduğu şey kökendir: geçmiş, her değişiklik için kimin imza attığını kaydetmeye devam eder; bu, DCO'nun 2004 yılında korunması için getirildiği özelliktir.

Bu geçmişin kiraladığınız sunucu için anlamı

• Lisans, sağlayıcınızın başlattığı çekirdeği neden okuyup yeniden derleyebildiğinizin ve özel mülk yazılımların neden üzerinde çalışabildiğinin sebebidir.
• Monolitik tasarım, tek bir sürücü hatasının neden tüm makineyi yeniden başlattığının ve çekirdek dışı bir modülün neden her çekirdek yükseltmesinde yeniden derlenmesi gerektiğinin sebebidir.
• Sürüm modeli, sürüm numarasının size neden çok az şey anlattığının, buna karşılık dalın ve kullanım ömrü sonu tarihinin neden neredeyse her şeyi açıkladığının sebebidir.
• Sanallaştırma türü, neler yapabileceğinizi belirler: KVM üzerinde kendi çekirdeğinizi başlatıp modül yükleyebilirsiniz; ancak ana makine çekirdeğini paylaşan konteyner sanallaştırmasında uname -r ana makinenin sürümünü gösterir, modprobe başarısız olur ve çeşitli sysctl değerleri salt okunur durumdadır.

FAQ

Linux çekirdeği neden GPLv3 değil de hala GPLv2 lisansına sahip?

Torvalds, 2007 yılında GPLv3'e geçmemeye karar verdi. Bunun temel nedeni, GPL kodunu içeren bir cihazın, bu kodun değiştirilmiş bir sürümünü de kabul etmesini zorunlu kılan "anti-tivoisation" şartıdır. Torvalds, kilitli donanımları üreticinin kendi ticari kararı olarak değerlendirmektedir. Ayrıca, çekirdekteki telif hakları binlerce katkıda bulunan kişiye ait olduğundan ve başvurulabilecek bir hak devri sözleşmesi bulunmadığından, lisans değişikliği pratikte neredeyse imkansızdır. Çekirdek yalnızca GPL-2.0 lisansına sahiptir; bu nedenle yalnızca GPLv3 altında sunulan kodlar çekirdeğe dahil edilemez.

Linux çekirdeği monolitik bir çekirdek midir yoksa mikro çekirdek mi?

Yüklenebilir modüllere sahip monolitik bir çekirdektir. Sürücüler ve dosya sistemleri çekirdeğin adres alanı içinde çalışır; lsmod komutu o an yüklü olanları listeler. Bu yapının bir tarafında hız avantajı, diğer tarafında ise etki alanı riski bulunur: hatalı bir modül tüm makinenin çökmesine (kernel panic) neden olabilir; mikro çekirdek mimarisinde ise sadece ilgili süreç etkilenirdi. 1992'den bu yana kullanıcı alanında çalışan FUSE dosya sistemleri ve çekirdeğin çalıştırmadan önce doğruladığı eBPF programları sayesinde bu durum esnemiştir.

Mainline, stable ve longterm çekirdek sürümleri arasındaki fark nedir?

Mainline, Torvalds'ın ağacıdır ve her 9 ila 10 haftada bir yayınlanır; yeni özellikler ilk olarak burada yer alır. Stable sürümü, en güncel mainline sürümünü temel alır ve birkaç hafta boyunca hata düzeltmeleri alır. Longterm dalları ise yıllarca düzeltme almaya devam eder ve dağıtımların kendi çekirdeklerini oluştururken temel aldıkları sürümlerdir. kernel.org, mevcut longterm dallarını ve her biri için öngörülen kullanım ömrü sonu tarihlerini listeler.

Linux çekirdeği yapay zeka tarafından yazılan kodları kabul ediyor mu?

Evet, Aralık 2025'te kabul edilen bir politika çerçevesinde kabul edilmektedir. Kullanılan araç bir Assisted-by: etiketi ile belirtilmeli, yapay zeka temsilcisi bir Signed-off-by satırı eklememeli ve üretilen kod GPL-2.0 ile uyumlu olmalıdır. Kodu gönderen insan, yamayı incelediğini ve Developer Certificate of Origin kapsamında sorumluluğu üstlendiğini belirten "sign-off" işlemini yapar.

Bir sunucuda hangi çekirdek sürümünü çalıştırmalıyım?

Neredeyse her durumda, dağıtımınızın desteklediği sürümü kullanmalısınız. Dağıtım çekirdeği; bir longterm dalı, geriye dönük taşınan (backported) düzeltmeler ve satıcının testlerinden oluşan bir yapıdır. Sağlayıcınızın sunduğu imajlar ve destek anlaşmaları bu çekirdek yapısını temel alır. Belirli bir sürücüye veya özelliğe ihtiyaç duyduğunuzda daha yeni bir mainline çekirdeği derleyebilirsiniz; ancak geçiş yapmadan önce geçeceğiniz dalın kullanım ömrü sonu tarihini kontrol etmelisiniz.