Major sürüm yükseltmesinin changelog'unu breaking change özeti + adım adım geçiş listesine çevir
Yüzlerce satırlık changelog yerine elinde şunlar olur: seni ilgilendiren breaking change'lerin risk sıralı tablosu, branch açmaktan doğrulamaya kadar onay kutulu bir geçiş listesi ve sessizce kırılabilecek noktaların ayrı uyarı listesi.
Kanca
Bir bağımlılığın ya da framework'ün major sürümü çıktı, changelog yüzlerce satır. "Şimdi değil" deyip erteliyorsun; ama ertelenen yükseltmeler birikince neyin kırılacağını kimsenin net bilmediği, geri dönüşü zor bir yığına dönüşüyor.
Hamle — Claude / ChatGPT (ikisi de çalışır)
Rolün: bağımlılık ve framework major sürüm geçişlerinde deneyimli, kıdemli bir yazılım mühendisisin.
Sana bir bağımlılığın (kütüphane/framework) major sürüm yükseltmesine ait changelog / release notes metnini vereceğim. Görevin bunu iki şeye çevirmek: (1) risk sıralı bir breaking change özeti, (2) güvenli uygulama sırasına dizilmiş, adım adım bir geçiş listesi.
Kurallar:
- Sadece aşağıda verdiğim metne dayan. Metinde olmayan API, davranış, varsayılan değer ya da taşıma adımı UYDURMA.
- Bir bilgi (ör. deprecated bir şeyin yeni karşılığı, taşıma yolu) metinde yoksa o satıra aynen "EKSİK: changelog'da belirtilmemiş, sürüm dokümanına bakılmalı" yaz. Tahmin yürütme, boşluğu doldurma.
- Emin olmadığın yeri "kesin değil" diye işaretle.
- Kod örneğini yalnızca changelog'da geçiyorsa kullan; kendin örnek kod uydurma.
Çıktıyı şu üç bölümde ver:
BÖLÜM 1 — Breaking change özeti (tablo)
Her breaking change için bir satır:
| Değişiklik | Etki (Yüksek/Orta/Düşük) | Beni ilgilendirir mi | Ne yapmam gerekiyor |
"Beni ilgilendirir mi" sütununu aşağıda vereceğim "kullandığım parçalar" listesine göre doldur; parça listede yoksa "belirsiz - kontrol et" yaz.
BÖLÜM 2 — Geçiş listesi (checklist)
Onay kutulu ([ ]) maddeler halinde, uygulama sırasına göre: önce hazırlık (branch aç, yedek, mevcut testleri çalıştır), sonra kod değişiklikleri, sonra doğrulama. Her maddeyi tek cümlelik, yapıldı/yapılmadı diye işaretlenebilir somut bir eylem olarak yaz.
BÖLÜM 3 — Sessiz kırılma uyarıları
Hata fırlatmadan davranışı değişen (varsayılan değer, dönüş tipi, sıralama vb.) maddeleri ayrı listele; bunları özellikle vurgula çünkü testte fark edilmezler.
---
Mevcut sürüm: [BURAYA YAZ]
Hedef sürüm: [BURAYA YAZ]
Kullandığım parçalar/modüller (kabaca): [BURAYA YAZ — bilmiyorsan "bilmiyorum" yaz]
Changelog / release notes:
[BURAYA YAPIŞTIR]Çıktı
Yüzlerce satırlık changelog yerine elinde şunlar olur: seni ilgilendiren breaking change'lerin risk sıralı tablosu, branch açmaktan doğrulamaya kadar onay kutulu bir geçiş listesi ve sessizce kırılabilecek noktaların ayrı uyarı listesi. İlk taslak birkaç dakikada çıkar.
Kariyer çentiği
Ertelenen bir yükseltmeyi "changelog çok uzun" bahanesinden çıkarıp planlı, izlenebilir bir işe çevirdiğinde, ekipte teknik riski görünür kılan ve önünü açan kişi sen olursun.
Sınır
AI senin kod tabanını görmez; "beni ilgilendirir mi" sütununu ve özellikle sessiz davranış değişikliklerini kendi testlerinle doğrulamadan kesin sayma, ayrıca prompta iç kaynak kodu değil sadece changelog metnini yapıştır.
Örnek — bu prompt ne üretir?
Örnek girdi
Mevcut sürüm: 3.14
Hedef sürüm: 4.0
Kullandığım parçalar/modüller (kabaca): defineSchema ile şema tanımlama, validate() fonksiyonu, tarih doğrulama, hata mesajlarını kullanıcıya gösterme
Changelog / release notes:
X Kütüphanesi 4.0.0
BREAKING CHANGES
- validate() artık geçersiz veride exception fırlatmıyor; bunun yerine { ok, errors } nesnesi döndürüyor. Eski davranış için validateOrThrow() kullanın.
- defineSchema() içindeki `strict` seçeneği artık varsayılan olarak true (önceden false idi). Şemada tanımlı olmayan alanlar reddedilir.
- parseDate() kaldırıldı.
- Doğrulama hatalarının döndürülme sıralaması artık şema tanım sırasına göre (önceden alfabetikti).
- Minimum Node sürümü 18'e yükseltildi.
DEPRECATIONS
- schema.extend() yerine schema.merge() kullanın.
- legacyMode kaldırıldı.Çıktı
BÖLÜM 1 — Breaking change özeti
| Değişiklik | Etki | Beni ilgilendirir mi | Ne yapmam gerekiyor |
|---|---|---|---|
validate() artık exception fırlatmıyor, { ok, errors } döndürüyor | Yüksek | Evet — validate() kullanıyorum | validate() çağrılarını dönüş nesnesini (ok, errors) okuyacak şekilde güncelle; fırlatma davranışı gereken yerlerde validateOrThrow() kullan |
defineSchema() içinde strict varsayılanı false → true | Yüksek | Evet — defineSchema() kullanıyorum | Şemalarını gözden geçir; şemada tanımsız alanların artık reddedileceğini doğrula, kasıtlı gevşek şemalara strict: false ver |
parseDate() kaldırıldı | Orta | Evet — tarih doğrulama kullanıyorum | EKSİK: changelog'da yeni karşılığı belirtilmemiş, sürüm dokümanına bakılmalı |
| Doğrulama hatalarının sıralaması alfabetik → şema tanım sırası | Orta | Evet — hata mesajlarını gösteriyorum | Hata sırasına bağlı gösterim/testleri güncelle (ayrıca BÖLÜM 3) |
| Minimum Node sürümü 18 | belirsiz - kontrol et | belirsiz - kontrol et | Çalışma ve CI ortamının Node 18+ olduğunu doğrula |
schema.extend() deprecated → schema.merge() | belirsiz - kontrol et | belirsiz - kontrol et | extend() kullandığın yer varsa merge() ile değiştir |
legacyMode kaldırıldı | belirsiz - kontrol et | belirsiz - kontrol et | EKSİK: changelog'da yeni karşılığı belirtilmemiş, sürüm dokümanına bakılmalı |
BÖLÜM 2 — Geçiş listesi
Hazırlık
- [ ]
upgrade/x-4adında yeni bir branch aç - [ ] Mevcut testleri çalıştır, yeşil olduklarını kaydet (karşılaştırma temeli)
- [ ] Bağımlılığı 4.0.0'a yükselt ve kilit dosyasını güncelle
Kod değişiklikleri
- [ ] Tüm
validate()çağrılarını{ ok, errors }dönüşünü işleyecek şekilde güncelle; fırlatma gereken yerlerdevalidateOrThrow()kullan - [ ]
defineSchema()çağrılarındastrict: trueetkisini gözden geçir, gevşek kalması gerekenlerestrict: falseekle - [ ]
parseDate()kullanımlarını bul (EKSİK: yeni karşılığı için sürüm dokümanına bak) - [ ]
schema.extend()kullanımlarınıschema.merge()ile değiştir - [ ]
legacyModebağımlılıklarını kaldır (yeni karşılık için sürüm dokümanına bak)
Doğrulama
- [ ] Çalışma ortamını Node 18+ yap ve doğrula
- [ ] Testleri tekrar çalıştır; hata sırasına duyarlı olanları güncelle
- [ ]
validate()dönüş tipini kullanan akışları elle test et
BÖLÜM 3 — Sessiz kırılma uyarıları
validate()artık fırlatmıyor (dönüş tipi değişikliği): eskitry/catchbloğu hiç tetiklenmez; geçersiz veri sessizce geçip akışın ilerisine sızabilir.strictvarsayılanı true oldu: önceden geçen "fazladan alanlı" veri artık reddedilir; fırlatmaya değil dönüş değerine bakan yerlerde davranış sessizce değişir.- Hata sıralaması şema tanım sırasına geçti: "ilk hatayı göster" gibi mantıklar farklı mesaj gösterir; test yeşil kalsa bile kullanıcıya giden mesaj değişebilir.
ÜRETİM: TEM 2026 · CLAUDE Bu kayıt eşlenmiş örnek girdi ve çıktı içerir. Model koşumu kanıtı yoktur — kendi verinle doğrulamadan karar girdisi yapma.
Kendi verinle çalıştır
Verini aşağıya yapıştır; prompt seninkiyle birleşip çalıştırmaya hazır tek bloğa dönüşsün. Sonra tek dokunuşla Claude ya da ChatGPT'de aç.
Rolün: bağımlılık ve framework major sürüm geçişlerinde deneyimli, kıdemli bir yazılım mühendisisin.
Sana bir bağımlılığın (kütüphane/framework) major sürüm yükseltmesine ait changelog / release notes metnini vereceğim. Görevin bunu iki şeye çevirmek: (1) risk sıralı bir breaking change özeti, (2) güvenli uygulama sırasına dizilmiş, adım adım bir geçiş listesi.
Kurallar:
- Sadece aşağıda verdiğim metne dayan. Metinde olmayan API, davranış, varsayılan değer ya da taşıma adımı UYDURMA.
- Bir bilgi (ör. deprecated bir şeyin yeni karşılığı, taşıma yolu) metinde yoksa o satıra aynen "EKSİK: changelog'da belirtilmemiş, sürüm dokümanına bakılmalı" yaz. Tahmin yürütme, boşluğu doldurma.
- Emin olmadığın yeri "kesin değil" diye işaretle.
- Kod örneğini yalnızca changelog'da geçiyorsa kullan; kendin örnek kod uydurma.
Çıktıyı şu üç bölümde ver:
BÖLÜM 1 — Breaking change özeti (tablo)
Her breaking change için bir satır:
| Değişiklik | Etki (Yüksek/Orta/Düşük) | Beni ilgilendirir mi | Ne yapmam gerekiyor |
"Beni ilgilendirir mi" sütununu aşağıda vereceğim "kullandığım parçalar" listesine göre doldur; parça listede yoksa "belirsiz - kontrol et" yaz.
BÖLÜM 2 — Geçiş listesi (checklist)
Onay kutulu ([ ]) maddeler halinde, uygulama sırasına göre: önce hazırlık (branch aç, yedek, mevcut testleri çalıştır), sonra kod değişiklikleri, sonra doğrulama. Her maddeyi tek cümlelik, yapıldı/yapılmadı diye işaretlenebilir somut bir eylem olarak yaz.
BÖLÜM 3 — Sessiz kırılma uyarıları
Hata fırlatmadan davranışı değişen (varsayılan değer, dönüş tipi, sıralama vb.) maddeleri ayrı listele; bunları özellikle vurgula çünkü testte fark edilmezler.
---
Mevcut sürüm: [BURAYA YAZ]
Hedef sürüm: [BURAYA YAZ]
Kullandığım parçalar/modüller (kabaca): [BURAYA YAZ — bilmiyorsan "bilmiyorum" yaz]
Changelog / release notes:
[BURAYA YAPIŞTIR]Yapıştırdığın veri tarayıcından çıkmaz — WhiteYaka'ya gönderilmez. Prompt panoya kopyalanır; açılan sohbete Ctrl/⌘ + V ile yapıştırırsın.
i Bu föy örnek girdi ve çıktı içerir; yapısal doğrulama ve ölçütlü prompt koşumu henüz kaydedilmedi.
Bülten kaydı kapalı.
Bu sayfa e-posta adresi toplamaz ve liste kaydı başlatmaz. 160 hamlenin tamamı giriş yapmadan açık.