Her değişiklik türü için release notes örnekleri

En iyi release notes örnekleri kısadır, kimin etkilendiğini söyler ve sonra ne yapılacağını belirtir. Aşağıda yayımlayacağınız her değişiklik türü için, neden işe yaradığıyla birlikte bir örnek var; böylece şekli kopyalayıp kendi bilgilerinizi koyabilirsiniz.

Her örnek, Tidepool adında hayali bir faturalama uygulaması için uydurulmuştur.

İyi release notes örneklerinin ortak yanı nedir?

Kullanıcılara neyin değiştiğini ve bu konuda bir şey yapmaları gerekip gerekmediğini, kullanıcıların kendi kelimeleriyle söylerler. Her değişiklik türünün farklı bir işi var, o yüzden şekil bunlar arasında kayar.

İyi bir yeni özellik notu nasıl görünür?

İyi bir özellik notu, okuyucunun artık ne yapabildiğiyle açılır ve onu alan planları ya da rolleri adlandırır. Uygulamayı atlar.

Faturaları müşterinin dilinde gönderin. Artık her müşteri için bir dil seçebilirsiniz ve faturaları, hatırlatmaları ve ödeme sayfası ona uyar. Fransızca, Almanca, İspanyolca ve Portekizce tüm planlarda mevcut. Müşterinin sayfasında Faturalama tercihleri altından ayarlayın.

Başlık okuyucunun yüksek sesle söyleyeceği bir ifadedir ve gövde kapsamı ve yeri verir. Sadece kalın satıra göz atan okuyucu yine de neyin yayımlandığını bilir. Daha geniş yöntem release notes nasıl yazılır yazısında.

İyi bir iyileştirme notu nasıl görünür?

İyileştirme notu, okuyucunun hissedeceği bir değişikliği anlatır ve varsa üzerine ölçülmüş bir sayı koyar. Sayı yoksa, okuyucunun artık yapmak zorunda olmadığı şeyi söyleyin.

Fatura listesi yaklaşık üç kat daha hızlı açılıyor. 5.000’den fazla faturası olan hesaplar liste için yaklaşık dokuz saniye beklerdi. Artık yaklaşık üç saniyede açılıyor. Hiçbir işlem gerekmiyor.

“Performans iyileştirmeleri” okuyucuya hiçbir şey söylemez, dokuza karşı üç saniye ise pazartesi sabahı kontrol edebilecekleri bir iddiadır. Kapanıştaki “Hiçbir işlem gerekmiyor” her okuyucunun sorduğu soruyu cevaplar.

İyi bir hata düzeltmesi notu nasıl görünür?

Hata düzeltmesi notu, koddaki nedeni değil kullanıcının gördüğü belirtiyi anlatır ve bir şeyi yeniden yapmaları gerekip gerekmediğini söyler. Kimsenin fark etmediği düzeltmeler en alttaki listeye girebilir.

Düzeltildi: hatırlatma e-postaları vade gününde iki kez gönderiliyordu. Bazı müşteriler, faturaları bir ayın son gününe denk geldiğinde iki özdeş hatırlatma aldı. Bu düzeltildi. Daha önce gönderilen hatırlatmalar etkilenmiyor ve kimsenin bir şeyi yeniden göndermesi gerekmiyor.

Başlık “Düzeltildi” ile başlar, böylece göz gezdiren biri bir bakışta ayırabilir ve gerçek koşul (ayın son günü) hemen arkasından gelir.

Breaking change için release notes nasıl yazılır?

Breaking change notu tarihle ve etkilenen grupla açılır, sonra geçişi aynı girdide verir. Release notes’ta ilk sıraya gider, çünkü okuyucunun kaçırmaması gereken tek girdidir.

Webhook imzaları 1 Aralık 2026’da zorunlu oluyor. O tarihten itibaren Tidepool imzasız webhook payload’ları göndermeyi bırakıyor. Bu, webhook’ları Tidepool-Signature header’ını doğrulamadan alan herkesi etkiliyor. Geçmek için header’ı, Ayarlar, Geliştiriciler altındaki sır ile doğrulayın. İmzaları zaten doğruluyorsanız, hiçbir işlem gerekmiyor.

Tarih başlıktadır, böylece göz gezdirmeye dayanır. Etkilenen grup yaptığı işle adlandırılır ve son cümle zaten sorunsuz olanları serbest bırakır, bu da destek yükünü azaltır. Breaking change’ler rehberi, bir değişikliğin breaking sayılıp sayılmayacağına nasıl karar verileceğini anlatır.

Bir güvenlik düzeltmesi notu neye benzer?

Güvenlik notu neyin açıkta kaldığını, birinin istismar edip etmediğini, kimin etkilendiğini ve ne yapmaları gerektiğini söyler. Olgusal ve sakin tutun.

Güvenlik: parola sıfırlama bağlantıları yeniden kullanılabiliyordu. 3 ile 17 Eylül 2026 arasında, bir parola sıfırlama bağlantısı bir kez kullanıldıktan sonra da geçerli kalıyordu. İstismar edildiğine dair bir iz bulmadık. Düzeltildi ve bekleyen tüm sıfırlama bağlantıları geçersiz kılındı. O aralıkta bir sıfırlama istediyseniz, yeni bir bağlantı isteyin.

Kesin aralık okuyucunun kendi maruziyetini değerlendirmesini sağlar ve istismar hakkındaki cümle, herkesin sorduğu ilk soruyu cevaplar. “Olası bir sorun” gizleme gibi okunur, o yüzden bildiğinizi söyleyin.

Deprecation bildirimi nasıl yazılır?

Deprecation bildirimi neyin kaldırıldığını adlandırır, kesin bir bitiş tarihi verir ve yerine geçeni gösterir.

v1 faturalar endpoint’i deprecated oldu ve 1 Mart 2027’de sona eriyor. GET /v1/invoices 1 Mart 2027’ye kadar çalışmaya devam eder, sonra 410 Gone döndürür. Aynı alanları artı currency döndüren GET /v2/invoices kullanın. v1’den dönen yanıtlar artık bitiş tarihini içeren bir Sunset header’ı taşıyor. Yan yana bir geçiş kılavuzu dokümanlarda.

Endpoint adı başlıktadır, çünkü etkilenenler onu arar ve yerine geçen kaldırılanın yanında durur. Sunset header’ı geliştiricilere hangi çağrıların hâlâ eski sürümü kullandığını söyler. Daha uzun anlatım bir API’yi deprecate etmek yazısında.

Mağaza release notu nasıl görünür?

Mağaza notu iki ya da üç düz cümledir, çünkü çoğu insan sadece ilk satırı okur. Kullanıcının fark edeceği değişiklikle başlayın.

Kâğıt bir fişi tarayın, Tidepool tutarı, tarihi ve satıcıyı doldursun. Karanlık mod artık telefon ayarınızı izliyor. Ayrıca bir bildirimden fatura açarken oluşan bir çökmeyi düzelttik.

En yararlı değişiklik ilk sırada ve düzeltme, çöken durumu adlandırır. Sürüm numarası ve “hata düzeltmeleri ve iyileştirmeler” yok. Mobil uygulamalar için release notes mağazaya özgü kuralları ele alır.

Dahili release notu neleri içermeli?

Dahili not, destek ve satış için olan sürümdür. Herkese açık notun dışarıda bıraktığını ekler: ne söylenecek ve neyin vaat edilmeyeceği.

Çok dilli faturalar bugün yayımlandı (tüm planlar). Destek: müşteriler dili Faturalama tercihleri altından ayarlıyor ve mevcut faturalar özgün dillerini koruyor. İtalyanca henüz mevcut değil. Satış: bu her plana açık, o yüzden onu bir yükseltme olarak konumlandırmayın.

Her hedef kitle kendi etiketli satırını alır ve not sınırı (“İtalyanca henüz mevcut değil”) bir müşteri sormadan önce çizer. Dahili release notları makalesi biçimi ve kanalları ele alır.

Kötü bir release notu nasıl görünür, yeniden yazılmış hâliyle?

Kötü bir release notu, okuyucunun ne aldığını değil ekibin ne yaptığını listeler. Sonucu öne alıp dahili sözlüğü silerek düzeltin.

Önce:

v3.8.1 Hatırlatma zamanlayıcısı refactor edildi. ReminderJob’daki race condition düzeltildi. bull 4.12’ye güncellendi. Çeşitli iyileştirmeler.

Sonra:

Hatırlatma e-postaları artık iki kez gitmiyor. Faturası bir ayın son gününe denk gelen müşteriler iki hatırlatma alabiliyordu. Bu düzeltildi ve daha önce gönderilen hatırlatmaların yeniden gönderilmesi gerekmiyor. Hiçbir işlem gerekmiyor.

3.8.1’de ayrıca: bull 4.12’ye güncellendi.

Bağımlılık güncellemesi bir alt bilgi satırına indi ve race condition, bir müşterinin tanıyacağı bir belirtiye dönüştü.

Release notes sürümler arasında nasıl tutarlı tutulur?

Her girdiyi değişiklik merge edildiğinde taslak olarak yazın ve yayımlanmadan önce bir insana onaylatın.

Changeloop böyle çalışır: merge edilen her pull request’ten AI ile bir girdi taslağı hazırlar ve onaylanması için bir insana bekletir. Onay adımı, bir editörün yukarıdaki kuralları uyguladığı yerdir. Önce biçime karar vermek için release notes şablonundan başlayın, bitmiş sayfaların nasıl göründüğü için de changelog örneklerine bakın.

FAQ

Yeni release notes nedir? Yeni release notes, bir ürünün son sürümüyle birlikte yayımlanan, neyin değiştiğini ve kullanıcıların ne yapması gerektiğini anlatan mesajdır. Özellikleri, iyileştirmeleri, düzeltmeleri ve breaking change’leri kapsar.

Release note ile changelog arasındaki fark nedir? Changelog her şeyi tutar, tam geçmişi isteyen herkes için. Release note ondan seçer: tek bir sürüm, sürümün kendilerini ilgilendirip ilgilendirmediğine karar veren okuyucular için yazılmış. Daha ayrıntılı karşılaştırma changelog vs release notes yazısında.

Release notes ne anlama gelir? Release notes, kullanıcılara bir sürümde neyin değiştiğini anlatır. İfade, bir uygulama mağazasındaki “Yenilikler” metninden bir şirket sitesindeki bir sayfaya kadar, neyin yayımlandığını açıklayan her şeyi kapsar.

Her release note girdisi ne kadar uzun olmalı? Çoğu girdi için iki ila dört cümle yeter: sonuç, kimin etkilendiği ve ne yapılacağı. Bir breaking change ya da güvenlik düzeltmesi, bir tarih ya da geçiş gerektirdiği için daha uzun sürebilir.

Bu yazıdaki teknik iddialar bağımsız olarak kontrol edilmedi. Yanlış bir şey varsa bize söyle, düzeltelim.

changeloop'ta ilgili sayfalar: Release notu şablonu, Changelog örnekleri