Sürüm Notu Örnekleri: Kopyalayabileceğiniz 5 Hazır Not
Bu sürüm notu örnekleri beş yaygın yayın durumunu kapsıyor: bir SaaS uygulamasında özellik duyurusu, acil düzeltme, uygulama mağazası metni, tarihli bir API değişikliği ve şirket genelinde yeni bir BT aracına geçiş. Ürün, mühendislik ve BT ekipleri bu sürüm notu örneklerinden herhangi birini metin olarak kopyalayabilir, her birinin eşleşen bir PDF'i de var.
İyi sürüm notu örneklerinin ortak noktası: ürünü, sürümü, yayın tarihini ve platformu net biçimde belirten bir açılış satırı.
Mağaza güncellemeleri: her düzeltmeye kendi satırını verin, eski sorunu ve yeni davranışı yazın.
Güçlü ve zayıf notlar: güçlü maddeler kullanıcıya sağlanan faydayı anlatır, zayıf maddeler iç bileşenleri sıralar.
Belirsiz maddeler: bu sayfadaki örnek sürüm notları ve değişiklik günlüğü örnekleri her düzeltmeyi tek tek adlandırır. Boş bir şablon için Sürüm Notu Şablonu'nu açın.
İyi Bir Sürüm Notu Örneğini Ne Oluşturur
Galerideki her örnek, bu yedi ölçüte numarasıyla atıfta bulunur.
- Sürüm ve tarih içeren başlık satırı. Ürün adıyla, sürüm veya yapı numarasıyla, yayın tarihiyle başlayın. Platforma göre değişiyorsa nerede yayınlandığını da ekleyin (web, iOS, API). Bu satırı kaçıran okur, notun kullandığı sürüm için geçerli olup olmadığını anlayamaz.
- Üstte kısa bir özet. Herhangi bir listeden önce bir ila üç cümle, kimin etkilendiğini ve nasıl etkilendiğini söyler. Özet olmazsa okur doğrudan madde işaretlerinin içine düşer.
- Sonuç odaklı ifadeler. Her madde, okurun kazandığı ya da artık yaşamadığı bir şey olarak yazılır ("Artık ... yapabilirsiniz"). Zayıf ifadeler iç bileşenleri sıralar ("Arama dizinleme hattı optimize edildi").
- Türü belirten değişiklik etiketleri. Maddeler Düzeltildi veya Uyumsuz değişiklik gibi bir tür etiketi altında yer alır ve benzer maddeler bir arada gruplanır. Etiket olmazsa bir onarım ile yeni bir özellik aynı görünür.
- Önce ve sonra olarak yazılmış somut hata düzeltmeleri. Her düzeltme, birinin yaşadığı belirtiyi ürünün bugünkü davranışıyla eşleştirir ve satır başına bir düzeltme düşer. Zayıf sürüm tek bir genel satırla yetinir.
- Gerekli eylemler ve uyumsuz değişiklikler en başta belirtilir. Okurun yapması gereken her şey, son tarihiyle birlikte en üste yazılır. Gerekli bir şey yoksa not "Herhangi bir işlem gerekmez" der. Zayıf notlar uyumsuz değişikliği listenin ortasına gizler.
- Bilinen sorunlar ve yardım alınacak yer. Hâlâ bozuk olan her şey bir geçici çözümle ya da düzeltmenin geleceği tarihle verilir, kapanış satırı da okuru dokümanlara veya bir destek kişisine yönlendirir. Bunu atlamak hiçbir şeyin bozuk olmadığı izlenimi verir.

Kopyalamaya Değer 5 Sürüm Notu Örneği
İşte her biri bir yayın türünü temsil eden beş örnek. Ödünç alınabilecek en iyi sürüm notu örnekleri arasında saydığımız bu örneklerdeki tüm şirketler kurgusaldır.
Örnek 1: SaaS Özellik Lansmanı
B2B fatura uygulamasında tek bir özelliği duyuran bir ürün yöneticisi için.

- Başlık: Ledgerly 3.8 · 6 Mayıs 2026 · Web · Growth ve Scale planları
- Yeni: Faturalar artık kendi kendini takip ediyor
- Özet: Ledgerly artık belirlediğiniz bir takvime göre ödeme hatırlatıcıları gönderebiliyor, böylece finans ekipleri takip e-postalarını elle yazmayı bırakıyor. Growth ve Scale planlarında kullanılabilir.
- Artık neler yapabilirsiniz: fatura başına en fazla 3 hatırlatıcı ayarlayın (örneğin vade tarihinden 3 gün önce, vade tarihinde ve 7 gün sonra). Ödeme kaydedildiğinde hatırlatıcılar otomatik olarak durur. Her hatırlatıcı fatura markanızı kullanır.
- Nasıl kullanılır: (1) Ayarlar > Hatırlatıcılar bölümünü açın. (2) Otomatik hatırlatıcılar seçeneğini açın. (3) Bir takvim seçin veya kendi takviminizi ekleyin. (4) Kaydet'e tıklayın. Takvim, ödenmemiş her faturaya uygulanır.
- İstediniz, biz yaptık: Ledgerly geri bildirim panosundaki #412 numaralı özellik isteği (230 oy).
- Kullanılabilirlik: 20 Mayıs 2026 tarihine kadar tüm Growth ve Scale hesaplarına kademeli olarak sunuluyor.
- Bilinen sınırlama: hatırlatıcılar yalnızca İngilizce gönderilir. Daha fazla dil 2026'nın 3. çeyreği için planlanıyor.
- Yardım alın: help.ledgerly.example/reminders
Neden işe yarıyor: 1, 2, 3, 4 ve 7. ölçütler. Başlığı doğrudan sonucun kendisi.
Dikkat edin: yalnızca İngilizce sınırı Ledgerly'ye ait. Kendi özelliğinizin sınırlarını belirtin.
PDF indir - Faturalar artık kendi kendini takip ediyor
Örnek 2: Mobil Uygulama Mağazası Güncellemesi
Her iki uygulama mağazası için güncelleme metnini hazırlayan bir mobil ürün yöneticisi için.

- Başlık: Trailmate · 5.12 Sürümündeki Yenilikler · 2 Haziran 2026 · iOS ve Android
- Çevrimdışı haritalar artık arka planda iniyor, böylece telefonunuzu kilitleyip yürümeye devam edebilirsiniz.
- Yeni: yükseklik grafiğindeki bir tempo çizgisi, her tırmanışta nerede yavaşladığınızı gösteriyor.
- Düzeltildi: yürüyüş sırasında kamerayı açtığınızda GPS iziniz artık durmuyor.
- Düzeltildi: telefonunuz mil olarak ayarlıyken Apple Watch uygulaması artık mesafeyi mil olarak gösteriyor.
- Kapanış satırı: Bu sorunları düzeltmemize yardımcı olan bildirimler için teşekkürler. Sorularınız mı var? support.trailmate.example
Madde işaretleri ve satır sonlarıyla birlikte dört satır, Google Play'in 500 karakterlik sınırının 341'ini oluşturuyor.
Neden işe yarıyor: 1, 2, 3, 4, 5 ve 7. ölçütler. Her düzeltme, yürüyüşçünün ne gördüğünü adlandırıyor.
Dikkat edin: beşinci bir madde, metni Google Play'in 500 karakterlik sınırının üzerine çıkarabilir.
PDF indir - 5.12 Sürümündeki Yenilikler
Örnek 3: Hata Düzeltme Yama Sürümü
Zamanlama yazılımında canlı bir acil düzeltmeyi duyuran bir destek lideri için.

- Başlık: Rostra 2.14.1 acil düzeltmesi · 18 Haziran 2026 · Web, iOS, Android
- Özet: Bu acil düzeltme, 2.14.0 ile gelen iki sorunu gideriyor. Düzeltme tüm hesaplarda yayında. Herhangi bir işlem gerekmez.
- Düzeltildi: Mobil uygulamada onaylanan vardiya takasları, siz sayfayı yenileyene kadar web takviminde görünmüyordu. Onaylanan takaslar artık web'de 5 saniye içinde görünüyor.
- Düzeltildi: Fazla mesai uyarıları, haftası Pazartesi başlayan hesaplarda 40 saat yerine 38 saatte tetikleniyordu. Uyarılar artık 40 saatte tetikleniyor ve hatalı gönderilen uyarılar temizlendi.
- Etkilenen kullanıcılar: 16 ile 18 Haziran 2026 arasında fazla mesai uyarılarını kullanan, haftası Pazartesi başlayan hesaplar.
- Neden: hafta başlangıcı ayarı, hesabın saat dilimi yerine UTC olarak okunuyordu.
- Bilinen sorun: vardiya takaslarının CSV dışa aktarımları saatleri hâlâ UTC olarak gösteriyor. Düzeltme 25 Haziran 2026'da 2.14.2 ile geliyor.
- Yardım alın: support@rostra.example
Neden işe yarıyor: 1, 2, 5, 6 ve 7. ölçütler, en başta "Herhangi bir işlem gerekmez" ifadesiyle.
Dikkat edin: neden satırı. Sizinkini tek satırda tutun.
PDF indir - Rostra 2.14.1 acil düzeltmesi
Örnek 4: API Sürüm Değişikliği
Bir platform ekibi, tarihli bir API sürümünü entegratörlere duyuruyor.

- Başlık: Parcelo API sürüm 2026-07-01 · 1 Temmuz 2026'da yayınlandı · 15 Ocak 2027'ye kadar işlem gerekli
- Özet: 2026-07-01 sürümü, nakliye ücretlerinin nasıl döndürüldüğünü değiştiriyor ve bir alanı yeniden adlandırıyor. Entegrasyonunuz, yükseltme yapana kadar sabitlediğiniz sürümde çalışmaya devam eder. v1 etiket uç noktası 15 Ocak 2027'de çalışmayı durduracak.
- Uyumsuz:
GET /rates,amountdeğerini ondalık dize ("12.99") yerine kuruş cinsinden tam sayı (1299) olarak döndürüyor. - Uyumsuz:
carrieralanıcarrier_codeolarak yeniden adlandırıldı. - Yeni (uyumlu): her ücret kaydına
estimated_delivery(ISO 8601 tarihi) eklendi. - Kullanımdan kaldırıldı:
POST /v1/labels, 15 Ocak 2027'de sonlandırılacak. Bunun yerinePOST /v2/labelskullanın. - Nasıl yükseltilir: (1) Bir test ortamında
Parcelo-Version: 2026-07-01başlığını gönderin. (2) Fiyatları gösterdiğiniz her yerdeamountdeğerini 100'e bölün. (3)carrieryerinecarrier_codekullanın. (4) Etiket çağrılarını/v2/labelsadresine taşıyın. - Önce:
{"carrier": "UPS", "amount": "12.99"} - Sonra:
{"carriercode": "ups", "amount": 1299, "estimateddelivery": "2026-07-04"} - Yardım alın: docs.parcelo.example/changelog/2026-07-01 ve Parcelo geliştirici topluluğundaki #api kanalı.
Neden işe yarıyor: 1, 2, 3, 4, 6 ve 7. ölçütler. Son tarih ve sonlandırma tarihi en üstte yer alıyor.
Dikkat edin: amount türündeki uyumsuz değişiklik. Her tür değişikliği için önce ve sonra gösteren bir kod parçası verin.
PDF indir - Parcelo API sürüm 2026-07-01
Örnek 5: Şirket İçi BT Aracı Geçişi
Lojistik şirketi Northwind Freight'te yaklaşık 420 çalışana bir aracı duyuran BT operasyonları için.

- Başlık: BT sürümü: Vaultkey parola yöneticisi · Geçiş 7 Temmuz ile 21 Temmuz 2026 arası · Tüm çalışanlar
- Özet: Vaultkey, ortak 'Team Passwords' elektronik tablosunun yerini alıyor. Herkes üç dalga halinde geçiyor ve tablo 28 Temmuz'da salt okunur oluyor.
- Geçiş dalgaları: Finans ve İK 7 Temmuz'da, Operasyon ve Sevkiyat 14 Temmuz'da, diğer herkes 21 Temmuz'da.
- Sizin için ne değişiyor: Vaultkey tarayıcı eklentisi şirket dizüstü bilgisayarlarına otomatik olarak yüklenir. Ekip kasaları, tablo sekmelerinin yerini alır. Tablo 28 Temmuz 2026'da salt okunur olur ve BT bunu 31 Ağustos 2026'da arşivler.
- Yapmanız gerekenler (dalganızdan sonraki 2 gün içinde işlem gerekli): (1) Vaultkey'den gelen davet e-postasını kabul edin. (2) En az 14 karakterlik bir ana parola belirleyin. (3) İsteğe bağlı: Vaultkey mobil uygulamasını yükleyin.
- Bilinen sorun: Safari'de eklentiyi Ayarlar > Eklentiler bölümünden kendiniz açın.
- Geri dönüş: BT, tablo yedeğini 31 Ağustos 2026'ya kadar saklar.
- Yardım alın: #it-help Slack kanalı ve Salı ile Perşembe günleri saat 14:00'teki BT ofis saatleri.
- Sorumlu: Priya Raman, BT Operasyonları.
Neden işe yarıyor: 1, 2, 3, 6 ve 7. ölçütler. Her işlemin bir son tarihi var.
Dikkat edin: her dalgaya yerleştirilmiş tarihler. Biri kayarsa notu yeniden gönderin.
PDF indir - BT sürümü: Vaultkey parola yöneticisi
Sürüm Notu Örneği Nasıl Uyarlanır
- Yayın türünüze en yakın galeri örneğini seçin. Yayın türüne göre seçin: özellik lansmanı, mağaza güncellemesi, acil düzeltme, API değişikliği veya şirket içi geçiş. Hiçbiri uymuyorsa boş Sürüm Notu Şablonu başlangıç noktasıdır.
- Ayrıntı düzeyini değişikliğin büyüklüğüne göre ayarlayın. Büyük lansmanlar bir arka plan açıklamasını ve görseli hak eder. Küçük ince ayarlar kısa bir özete eklenebilir, bir yama ise neyi düzelttiğiyle başlamalıdır.
- Tür etiketini ve kısa özeti koruyun. Geri kalan her şeyi kessiniz bile, hangi boyutta olursa olsun bu iki alanı tutun.
- Her maddeyi sonuç etrafında yeniden yazın. Mühendislik terimlerini, kullanıcının fark ettiği sonuçla değiştirin.
- "Bu beni etkiler mi?" sorusunu ilk cümlede yanıtlayın. Kimin fayda sağladığını ya da kimin işlem yapması gerektiğini belirtin.
- Bilgileri onu geliştiren ekiple doğrulayın. Yayınlanmadan önce davranışı, planları, platformları ve sürümü onaylamaları için yayına alan mühendislere sorun.
- Okurlar sonradan bulabilsin diye maddeyi etiketleyin. Ona bir tarih, bir değişiklik türü, bir ürün alanı etiketi ve kalıcı bir URL verin, her yayında aynı düzeni kullanın.
Sürüm Notlarına Ne Zaman İhtiyaç Duyulur
Birden fazla ürünü veya kurumsal kiracıyı kapsayan büyük yayınlar notlara en çok ihtiyaç duyar, çünkü yöneticilerin kendilerini etkileyeni görmek için ürüne, platforma ve sürüme göre filtrelemesi gerekir. Küçük yayınların da notlara ihtiyacı vardır: bir web uygulamasındaki tek bir yeni özellik (Örnek 1) ya da kullanıcılarının sorunlarının çözülüp çözülmediğini öğrenmek istediği bir acil düzeltme (Örnek 3).
Mobilde ve API'lerde katı sınırlar geçerlidir. Apple, güncelleme metnini App Store'da 4.000 karakterle sınırlar, Google ise Google Play'de 500 karaktere izin verir (Örnek 2). API entegratörleri, bir son tarih kod çalışması gerektirdiği anda değişiklikten haberdar olmalıdır (Örnek 4).
Şirket içi araçlar da sayılır. Not, destek çalışanlarına, satış temsilcilerine ve sistem sahiplerine neyin taşındığını, kime soracaklarını ve geri dönüşün nasıl işlediğini anlatır (Örnek 5).
Sık Yapılan Sürüm Notu Hataları
- Mühendislik jargonuyla yazmak veya biletleri olduğu gibi kopyalamak. "Arama dizinleme hattı optimize edildi" gibi bir satır ya da ham bir commit mesajı, okurun işi hakkında hiçbir şey söylemez. İnsanlar okumayı bırakır.
- Belirsiz "hata düzeltmeleri ve performans iyileştirmeleri" maddeleri. Hatayı bildiren kişi düzeltilip düzeltilmediğini göremez ve destek ekibine bir bilet daha gelir.
- Uyumsuz değişiklikleri ve zorunlu adımları listenin ortasına gizlemek. Çok sayıda maddeden biri olarak listelenen uyumsuz değişiklik fark edilmez ve son tarih geldiğinde entegrasyonlar bozulur.
- Özetsiz, uzun ve bölünmemiş bir günlük yayınlamak. Özet olmadan okurlar, kendilerini ilgilendiren bir şey olup olmadığını öğrenmek için her maddeyi taramak zorunda kalır.
- Kişiliğin neyin değiştiğini gizlemesine izin vermek. Bir değişikliği arayan okurlar, hiçbir özelliğin adını taşımayan esprili bir başlığın altında onu bulamaz.
Boş Sayfadan Kurtulun: Bunun Yerine Kaydedin
Her yayında demo yapan ekipler bu oturumu kaydedip Hinto AI'a verebilir. Hinto AI'ın "Yenilikler" şablonu notun ilk taslağını üretir. Hinto, Loom, Zoom ve YouTube bağlantılarını, MP4, MOV ve WebM yüklemelerini ve web uygulamasındaki ya da Chrome Uzantısındaki kendi kaydedicisinden alınan ekran kayıtlarını kabul eder.
Hinto videoyu işlerken düğme tıklamalarını ve ekran değişikliklerini algılar, ekran görüntülerini ve yazılı adımları çıkarır. Mühendislik için kaydedilmiş bir sprint demosu, aranabilir bir hata düzeltmeleri listesine dönüşebilir.
Yanlış okunan bir bölüm vurgulanıp görselleri dahil yeniden oluşturulabilir. Hazır not, kendi alan adınız altında herkese açık bir sayfada yer alabilir, 50'den fazla dilde üretilebilir veya Intercom, Notion, Confluence, GitHub ya da GitLab'a gönderilebilir.
Sürüm Notları SSS
Sürüm notlarında hangi etiketler kullanılmalı?
Altı etiketle sınırlı kalın: Yeni, Geliştirildi, Düzeltildi, Kullanımdan kaldırıldı, Uyumsuz değişiklik ve Bilinen sorun. Maddeleri etikete göre gruplamak, her okurun kendisini ilgilendiren bölüme atlamasını sağlar. Etiket olmadan düzeltmeler özelliklerin arasında kaybolur ve belirli bir kullanıcının ihtiyaç duyduğu değişikliği kaçırmak kolaylaşır.
Sürüm notlarına ekran görüntüsü veya video eklenmeli mi?
Gözle görülen değişiklikler için evet. İnsanlar yeniden tasarlanmış bir ekranı, açıklamalı bir görselden, GIF'ten veya kısa bir klipten düzyazıdan daha hızlı kavrar, dokümanlara yönlendirmek de notun içine bir kılavuz yazmaktan sizi kurtarır. Küçük düzeltmeler için metin yeterlidir.
API değişikliği için sürüm notları nasıl yazılır?
Entegratörlerin yapması gereken kod değişiklikleriyle ve kesinti tarihleriyle başlayın, bunu kendi başlığı altında ayırın. Altına uyumsuz değişiklikleri, yeni alanları ve kullanımdan kaldırılan uç noktaları satır başına bir madde olacak şekilde yazın, ardından yükseltme adımlarını numaralandırın. Örnek 4'te Parcelo'nun başlığı, her şeyden önce "15 Ocak 2027'ye kadar işlem gerekli" der.
İnsanların gerçekten okuduğu sürüm notları nasıl yazılır?
Her maddeye faydayla başlayın, örneğin "Büyük dışa aktarımlar artık zaman aşımına uğramıyor." İç bileşen adlarını bunun dışında tutun. Örnek 1, "Faturalar artık kendi kendini takip ediyor" ifadesiyle ve sonuç odaklı bir özetle açılır, ardından kurulum adımlarını verir.
İlgili Örnekler
Kullanım Kılavuzu Örnekleri, Bilgi Tabanı Örnekleri, Süreç Dokümantasyonu Örnekleri
