vcpkg Mayıs 2026 Güncellemesi: Sessiz Güç, Büyük Etki
Mayıs 2026 vcpkg güncellemesine bakınca ilk his şu oluyor: “Hani büyük bir araç sürümü yoktu, ama paket tarafı epey kıpırdamış.” İşin aslı şu ki, bu tip aylık registry yayınları bazen tek bir tool release’inden daha çok şey anlatıyor. Çünkü burada sadece sürüm numarası değişmiyor; ortamın nabzı tutuluyor, bağımlılıklar yeniden tartılıyor, port kalitesi de biraz daha sıkılaşıyor.
Garip gelecek ama, Ben vcpkg ile ilk kez 2020 sonbaharında, bir finans müşterisinde çalışırken ciddi şekilde uğraşmıştım. İstanbul’da ekip C++ tarafında onlarca kütüphaneyi farklı sunucularda elle derliyor, sonra da “neden bu makinede çalıştı da ötekinde patladı?” diye birbirine bakıyordu. O gün anladım ki paket yöneticisi dediğin şey sadece konfor değil; tekrar üretilebilirlik ve kriz anında nefes aldıran düzen demek.
Kısa bir not düşeyim buraya.
Bu Mayıs güncellemesinde de tam olarak o düzen hissi var. Boost 1.91, Qt 6.11, OpenCASCADE 8.0 gibi ağır toplar güncellenmiş; üstüne 27 yeni port eklenmiş, 500’ün üzerinde port elden geçmiş. Kulağa kuru bir changelog gibi geliyor olabilir ama kurumsal tarafta bunun karşılığı baya somut: daha az teknik borç, daha temiz tedarik zinciri (ben de ilk duyduğumda şaşırmıştım). Daha az “bu kütüphane niye artık build olmuyor?” telefonu.
Bu yayın ne söylüyor?
Önce rakamlara bakalım çünkü sayı bazen en dürüst şeydir. Curated registry’de toplam port sayısı 2.824’e çıkmış durumda. Bu tek başına bile önemli; ama asıl anlamlı nokta şu: her değişiklik sadece ilgili paketi değil, ona bağlı diğer paketleri de kontrol ederek geçiyorlar. Yanı iş kabaca marketten ürün almak gibi değil… Peki bunu neden söylüyorum? aynı anda neredeyse tüm raf düzenini korumaya çalışıyorlar.
İşte tam da bu noktada devreye giriyor.
Bir ara bunu Logosoft tarafında yürüttüğümüz bir kurumsal yazılım modernizasyonunda net görmüştüm; yıl 2024’tü. Müşteri Ankara’daki üretim sistemlerinde eski sürüm Boost yüzünden iki ayrı build hattını paralel taşımak zorunda kalıyordu. Her gün aynı dosyayı başka yerde aramak kadar can sıkıcı bir şey yoktu doğrusu! vcpkg’nın böyle kontrollü ilerlemesi işte o karmaşayı azaltıyor.
85 topluluk katkıcısı ve binlerce fork/star sayısı da ayrı mesaj veriyor: proje artık dar bir teknik çevrenin oyuncağı değil, bayağı canlı bir altyapı parçası olmuş. Açık konuşayım, bu büyüklükte projelerde asıl değer sadece yeni port eklemek değil; mevcutların kırılmadan kalmasını sağlamak.
Kurumsal tarafta paket yöneticisi seçimi çoğu zaman “hangi araç daha havalı” sorusu değil; “yarın sabah kaç saatimizi kurtaracak” sorusudur.
Büyük güncellemeler neden önemli?
Boost’un 1.91’e çıkması özellikle dikkat çekici çünkü Boost hâlâ birçok C++ kod tabanının omurgası gibi dürüyor. Yeni gelen boost-decimal portu küçük görünebilir ama finansal hesaplama yapan ekipler için bu tür ayrıntılar hayatı olabiliyor. Ben AZ-305 sınavına hazırlanırken mimarı kararların etkisini tekrar tekrar düşündüğümü hatırlıyorum; aynı mantık burada da geçerli: küçük görünen bağımlılık kararı sonradan mimariyi belirliyor (eh, fena değil)
Qt 6.11 işe bence enterprise UI uygulamaları için idare ederden iyiye geçen bir sıçrama olmuş. Tabiî her büyük Qt geçişi gibi burada — kendi adıma konuşayım — da biraz temkin gerekiyor; kağıt üstünde güzel duran yenilikler pratikte test ister. Bir kamu kurumunda gördüğüm kadarıyla özellikle GUI bağımlılığı yüksek uygulamalarda “sürüm yükseltelim” cümlesi hiç masum olmaz — önce ekranlar açılıyor mu, plugin’ler geliyor mu, yerelleştirme bozuluyor mu diye tek tek bakmak gerekiyor.
Çok konuştum, örnekle göstereyim.
Doğrusu, OpenCASCADE tarafı işe CAD/CAM/CAE çalışan ekipler için ciddi haber. Bu tarz motorlarda minör update gibi görünen şeyler bile geometri doğruluğunu etkileyebiliyor (evet, bayağı hassas konu) (bu konuda ikircikliyim). E peki, sonuç ne öldü? MuJoCo’nun 3.8.1’e çıkması da simülasyon kullanan ekiplerde güzel haber; robotik ya da fizik tabanlı test yapan startup’lar için yeni özelliklerden çok stabilite kıymetli oluyor.
Küçük ekip ile kurumsal yapı aynı şeyi yaşamıyor
Küçük ekipteyseniz yeni registry release’i gelir gelmez birkaç hedef platformda denersiniz, sorun çıkarsa hızlıca geri dönersiniz… bitti gitti. Kurumsalda işe durum öyle işlemiyor maalesef! On farklı takımın kullandığı ortak SDK varsa bir sürüm yükseltmesi önce güvenlik taramasından geçer, sonra uyumluluk kontrolünden geçer, en son change management kuyruğuna girer.
Büyük yapıda en çok sevdiğim şey disiplin olurdu diyemem açıkçası; bazen yavaşlık can sıkıyor. Kazanım belli: sürpriz azalıyor. Mesela vcpkg gibi katalog genişledikçe yönetim ihtiyacı artan yapılarda bu kontrollü yaklaşım fena değil hatta şart.
| Ana Alan | Etkisi | Kime Daha Fazla Fayda Sağlıyor? |
|---|---|---|
| Boost 1.91 | Daha yeni API’ler ve decimal desteği | Malı uygulamalar |
| Qt 6.11 | Daha taze framework özellikleri | Masaüstü/embedded GUI ekipleri |
| OpenCASCADE 8.0 | Kritik geometry kernel yükseltmesi | CAD/CAM geliştiren firmalar |
| 521 port update’i | Daha temiz bağımlılık zemini | Tüm kullanıcılar |
Sahada işin rengi nasıl değişiyor?
Lafı gevelemeden söyleyeyim: vcpkg’nın gücü yalnızca paket indirmek değil; aynı sonucu yeniden alabilmekte yatıyor. Geçen yıl Eylül ayında Gebze’de bir sanayi müşterisinde bunu birebir yaşadık — aynı kaynak kodu üç farklı makinede derleniyordu. Sonuç üç ayrı davranış gösteriyordu! Sorunun yarısı toolchain’in dağıklığıydı desek abartmış olmayız.
Düzgün tanımlanmış triplet kullanımı burada oyun değiştiriyor. Mesela x64-windows-static-md ile x64-windows arasındaki fark kağıt üzerinde basit görünür. Runtime davranışı bambaşka olabilir. Şey yanı… sembolik olarak ben bunu mutfakta aynı malzemeyle iki farklı yemek yapmaya benzetiyorum; biri hafif çıkar,öbürü yoğun olur.
Şuna dikkat: noktalar
- Paket güncellendi diye doğrudan production’a koşmayın.Kırılan transitive dependency olup olmadığına bakın.CMake preset’leri ile triplet eşleşmesini kontrol edin.
- Lisans etkisini atlamayın; özellikle ticari projelerde.
- Eğer bütçe darsa önce core ports’u sabitleyin, sonra çevresel paketlere geçin.
Neden bazı silinen portlar normaldir?
,
?p>Date many stale packages become maintenance burden and that’s not always visible from outside? Hayır tabi ki görünmez; fakat katalog büyüdükçe ölü ağırlıkları temizlemek lazım. cppcoro veya scylla-wrapper gibi kaldırılan portları görünce ilk refleks “neden silindi?” olur: Aslında cevap genelde basit:bakımı düşmüş,güncel ihtiyaçlara uymayan ya da kalite çıtasını artık taşımayan öğeler budur.
Bunu kendi pratiğimde de gördüm: Mart 2023’te Londra merkezli Avrupa operasyonu olan bir yazılım firmasına danışmanlık verirken eski kalan birkaç library yüzünden güvenlik taraması sürekli kırmızıya düşüyordu. Sız hiç denediniz mi? Bir yerde bırakıp gitmek yerine katalogdan gerçekten kullanılmayan parçayı ayıklamak bazen en doğru iştir.
E tabi bu süreç kusursuz olmuyor. Kimi zaman beklediğiniz kadar hızlı ilerlemiyor,kimi zaman community contribution eksikliği yüzünden bazı düzeltmeler gecikebiliyor. Yanı romantize etmeye gerek yok; açık kaynak güzel ama emek ister.
Bence bu yayın bize ne öğretiyor?
Açık konuşayım, benim okuduğum mesaj şu:vcpkg artık yalnızca Windows merkezli rahatlatıcı araç olmaktan çıktı,çoklu platform dünyasında ciddi katalog yöneticisi hâline geldi. OHOS triplet dokümantasyonu bunun sembolü gibi dürüyor. Bugün ARM64-OHOS yazıyorsanız yarın başka gömülü ortamlarla da uğraşırsınız; pazar genişliyor.
Vallahi,.NET tarafındaki hız değişimini takip eden biri olarak şunu da söyleyeyim:paket yönetimi olgunlaşmadığında DevOps akışı hep aksar. Azure DevOps’tan GitHub’a geçişlerde build standardizasyonu ne kadar kritikse,burada da dependency standardizasyonu o kadar kritik. Farklı katmanlar,aynı problem sınıfı aslında.
Eğer bugün sizde C++ tarafında kararsız build çıktıları varsa önerim net:önce kullanılan port listesini çıkarın,sonra minimum desteklenen tripleti belirleyin,ardından update ritmini ayarlayın (evet, doğru duydunuz). İlk adım karmaşayı azaltmak olsun,parlak teknoloji seçmek ikinci iş…
Sıkça Sorulan Sorular
vcpkg registry release ile tool release arasındaki fark ne?
Aslında ikisi farklı şeyler. Registry release, hani katalogdaki port tariflerini ve metadata’yı güncelliyor. Tool release işe vcpkg aracının kendisine gelen yenilikleri kapsıyor. Bu ay tool release yoktu, yanı odak tamamen package catalog üzerindeydi.
Neden bu kadar çok port güncelleniyor?
Paket çevrei canlıysa bağımlılıklar sürekli kıpırdıyor. Güvenlik yamaları, uyumluluk düzeltmeleri, upstream sürümlerdeki değişimler… Bunlar bir araya gelince yüzlerce porta dokunulması aslında çok normal. Tecrübeme göre bu hareketlilik sağlıklı bir ekosistemin işareti.
Kurumlarda vcpkg kullanmak mantıklı mı?
İlginç olan şu ki, Bence evet, özellikle tekrarlanabilir build isteyen C++ projelerinde gerçekten işe yarıyor. Ama şunu da söyleyeyim: sabit triplet stratejisi, CI doğrulaması. Lisans incelemesi yapmadan doğrudan girmek pek doğru olmaz.
Kaldırılan portlardan endişelenmeli mıyım?
Projenizde o portlardan biri varsa evet, mesela bir alternatif plan hazırlamak iyi olur. Kullanmıyorsanız genelde gerek yok. Açıkçası bakım yükünün azalması çoğu zaman herkes için daha iyi bir şey.
Kaynaklar ve İleri Okuma
Orijinal Microsoft duyurusu: What’s New in vcpkg (May 2026)
vcpkg Resmî Dokümantasyonu
vcpkg GitHub Deposu
CodeQL 2256 ile Sessiz Ama Güçlü Güvenlik Sıçraması: Bence Asıl Mesaj Bu:
.NET 11 Preview 5: Sessiz Gelen Yenilikler, Büyük Etki:
Kubernetes’te Doğrulama Artık Kod Değil: v136’da Ne Değişti?:
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
2 comments