Changelog örnekleri

1. Rutin bir SaaS sürümü

Yaygın durum: bir avuç kullanıcıya görünür değişiklik, geçiş yok, drama yok. Kısa çünkü sürüm küçüktü, onu doldurma dürtüsüne direnmek becerinin çoğudur.

## 20 Ağustos 2026

### Yeni
- Inbox'ta kayıtlı görünümler. Bir filtreyi bir kez sabitle ve
  kenar çubuğundan yeniden kullan.

### İyileştirildi
- Dışa aktarma işi artık büyük hesaplarda askıda kalmış gibi
  görünmek yerine ilerlemeyi bildiriyor.

### Düzeltildi
- Davet edilen üyeler artık ilk girişlerinden önce boş bir
  kontrol paneli görmüyor.

2. Kullanımdan kaldırma içeren bir API sürümü

Bir API changelog'unun okuyucusu tek bir şeye bakar: entegrasyonunun bozulmak üzere olup olmadığı ve ne kadar süresi olduğu. Bunu en üste koy ve bir tarih ver.

## Acme API 4.2 - 20 Ağustos 2026

### Kırıcı değişiklikler
- Tüm liste endpoint'lerinde `?page=` kaldırıldı. Önceki yanıttaki
  `nextCursor` değerini kullan.
  `?page=`, 1 Ekim 2026'dan sonra 400 döndürür.
  Geçiş adımları: acme.example/docs/pagination

### Yeni
- Webhook'lar tek bir projeyle sınırlandırılabilir.

### İyileştirildi
- Liste endpoint'leri 10.000 kayıttan büyük hesaplarda yaklaşık
  dört kat daha hızlı yanıt veriyor.

3. Bir mobil sürüm

Uygulama mağazaları kısaltılmış bir yenilikler alanı gösterir ve inceleme bir build'i günlerce tutabilir. Her iki gerçek de kaydı şekillendirir.

## iOS 3.4.0 - 20 Ağustos 2026

Çevrimdışı mod. Bağlantı olmadan aç, oku ve taslak hazırla;
tekrar çevrimiçi olduğunda her şey eşitlenir.

### Bu sürümde ayrıca
- Eski cihazlarda daha hızlı açılış.
- Mail'den paylaşılan bir bağlantı açılırken oluşan çökme düzeltildi.

4. Bir güvenlik düzeltmesi

Daha az söylemenin doğru olduğu tek kayıt. Kullanıcıların güncellemeleri gerektiğini bilmesi gerekir; başka hiç kimsenin henüz güncellemedikleri sürümü saldırmaya yetecek kadar hassas bir açıklamaya ihtiyacı yoktur.

## 20 Ağustos 2026

### Güvenlik
- Oturum jetonlarının doğrulanma şekli sıkılaştırıldı. Kendi
  barındırdığı kurulumlardaki hesaplar 4.2.1 veya sonrasına
  güncellemeli. Sorumlu bir şekilde bildirildi; istismar
  kanıtı yok. Ayrıntılar: acme.example/security/2026-08

5. Kötü bir örnek nasıl görünür

Buradaki her satır şekil olarak gerçek ve her satır bir hata:

## v2.3.7

- feature/inbox-refactor'dan PR #482 birleştirildi
- lodash 4.17.20 -> 4.17.21'e yükseltildi
- MembershipCache.resolve()'daki yarış durumu düzeltildi
- Çeşitli hata düzeltmeleri ve iyileştirmeler
- SavedView modeli yeniden düzenlendi (teşekkürler Dave!)

İyilerin ortak noktası

• Bir uygulamayı değil bir sonucu tanımlarlar. Kod tabanını hiç görmemiş bir okuyucu bile kaydın onu etkileyip etkilemediğini anlayabilir.
• Bazı şeyleri dışarıda bırakırlar. Bağımlılık güncellemeleri, refactor'lar, CI değişiklikleri ve dahili yeniden adlandırmalar yoktur ve bu yokluk geri kalanı okunabilir tutan şeydir.
• Maliyetli şeyi önce koyarlar. Bir şey bozulursa, bir tarihle birlikte ilk başlık odur.
• Okuyucunun kullanabileceği bir şekilde tarihlendirilirler: kullanıcıların sürümleri görebildiği yerde bir sürüm numarası, göremediği yerde bir tarih.
• Kasıtlı olarak sıkıcıdırlar. Ünlem işareti yok, pazarlama sıfatı yok, "duyurmaktan heyecan duyuyoruz" yok. Bir changelog okuyan insanlar bilgi arar ve önüne çıkan her şeye kızar.

Sık sorulan sorular

Bir changelog hangi formatı kullanmalı?

keepachangelog.com standarda en yakın şeydir ve bölüm adları (Added, Changed, Deprecated, Removed, Fixed, Security) yaygın olarak tanınır. Bölümlerin içindeki ifade tarzından çok daha az önemlidir. Belirsiz kayıtlarla tutarlı bir format, belirli kayıtlarla gevşek bir formattan daha kötüdür.

Ne sıklıkla yayımlamalıyız?

Sürümlerine uyan hangi ritimse o, ve tutarlı bir şekilde. Sürüm başına yayımlamak en basit kuraldır. Bir aylık sürümü tek bir gönderide toplamak, her bir değişikliği daha sonra bulmayı zorlaştırır, ki çoğu insan bir changelog'u tam da o zaman okur.

Changelog kendi sitemizde mi yoksa üçüncü taraf bir sayfada mı olmalı?

Yapabiliyorsan kendi sitende, çünkü trafik ve arama değeri orada birikir ve başkasının alan adındaki bir changelog, ürününün bir parçası değil ondan bir bağlantı uzağındadır. Bunu bağlantı verdiğin barındırılan bir sayfa yerine kendi renderladığın bir akış olarak sunmanın sebebi budur.

Kullanıcılar gerçekten changelog okuyor mu?

Küçük bir kesim düzenli olarak okur ve çok daha büyük bir kesim, bir şey altlarında değiştiği anda arar. O ikinci grup, sebebi değil belirtiyi yazmanın sebebidir: kendi kelimeleriyle başlarına ne geldiğini arıyorlar.

Daha fazla okuma: changelog ve release notu farkı, ve Keep a Changelog, gerçekten uygulanmış hâli.