Changelog Sayfası Nasıl Kurulur?

Changelog sayfasının temel yapısı

Her girdide yayın tarihini, varsa sürümü, değişen alanı ve kullanıcıya etkisini belirtin. En yeni kayıtları üstte sunabilirsiniz. Keep a Changelog yaklaşımı, önemli değişikliklerin insanlar için düzenlenmesini önerir; eklenen, değişen, kaldırılan ve düzeltilen özellikleri ayırır. Git commit listesini düzenlemeden kopyalamak yerine kullanıcıya hangi bilginin gerektiğine karar verin.

Sayfada arama ya da tür filtresi gibi araçlar girdi sayısı arttığında işe yarar; ama onlarca girdiye sahip bir sayfada bile en önemli iyileştirme, başlık ve tür etiketinin düzenli kullanımıdır. Sayfanın ana URL'si sabit olmalı; tek tek girdiler ayrı URL'lere taşınabilir fakat ana changelog sayfası, kullanıcıların alıştığı sabit adreste kalmalıdır.

Sürüm numarası mı, tarih mi?

Sürüm numarası, teknik değişiklikleri takip eden kullanıcılar için anlamlıdır; tarih, genel kullanıcı için daha sezgiseldir. İkisini birlikte kullanmak da mümkündür: tarihi ana gösterim, sürüm numarasını teknik ayrıntı olarak vermek. Format seçimini tutarlı uygulayın; girdiler arasında format değiştirmek, sayfayı okunmaz hale getirir.

Girdi formatı ve yazım kuralları

Önce neyin değiştiğini, ardından etkilenen kullanıcının ne yapacağını açıklayın. Örneğin gerçekten uygulanıp test edilmişse “Kesilen CSV yüklemesine kaldığınız yerden devam edebilirsiniz” yazılabilir. Desteklenmeyen “artık hiçbir kesinti olmaz” vaatleri eklemeyin. Geliştirici ürününde API sürümü, uyumluluk ve kaldırılma tarihi karar vermek için gerekli teknik bilgilerdir; iç görev adlarını veya gizli uygulama ayrıntılarını yayımlamayın.

Girdi başlıkları, ne değiştiğini net söyler ve tür etiketiyle eşleşir. Ekran görüntüsü veya kısa video, kullanıcı arayüzünü değişen girdilerde anlatıyı kısaltır; görselin alt metnini de unutmayın. Bir değişikliğin kullanıcıdan eylem gerektirmesi durumunda (eski yöntemin kaldırılması, ayarın taşınması), girdi içinde ayrıca belirtin ve kullanıcıya izleyeceği adımı yazın.

Bilinen sorunlar bölümü

Bilinen sorunları ilgili sürümün içinde veya ayrı bir durum alanında gösterebilirsiniz. Etkilenen sürümü, kullanıcıya etkisini ve varsa doğrulanmış geçici çözümü yazın. Çözüm yayımlandığında eski kaydı sessizce silmek yerine durumunu ve düzeltmenin sürümünü güncelleyin. Güvenlik açıklamalarının zamanını ve ayrıntısını güvenlik sorumlusuyla koordine edin.

Yayın akışı: kim yazıyor, ne zaman, nasıl onaylanıyor?

Changelog'un sürdürülebilirliği, tek bir kişiye değil bir akışa bağlıdır. Ürün geliştirme sürecinde her sürüm çıktığında changelog girdisi hazırlama adımını iş akışına ekleyin; sonradan toplanan notlar, ayrıntıları unutur. Girdiyi yazacak kişi, onaylayacak kişi ve yayınlanacak kanalları tanımlayın. Küçük ekipte bu üç rol bir kişiye düşebilir; amaç, akışın tanımlı olmasıdır.

Duyuruyu değişikliğin kullanıcılara açıldığı zamanla eşleştirin. Kademeli yayında kimlerin yeni özelliğe erişebildiğini belirtin; herkeste varmış gibi yazmayın. Acil düzeltmeler için hızlandırılmış kontrol ve duyuru yolu tanımlayın. Sosyal medya, ürün içi bildirim ve e-posta arasından değişikliğin kitlesine uygun olanları seçin.

Ürün içi bildirim ve changelog bağlantısı

Yeni bir özellik ilk kez açıldığında ürün içinde gösterilen kısa ipucu, changelog girdisine bağlanabilir. Kullanıcı ayrıntıyı istediğinde girdiye ulaşır; istemiyorsa akışına devam eder. Bu bağlantıyı aşırı kullanmayın; her küçük değişiklik için ürün içi bildirim çıkarmak, kullanıcının bildirimleri göz ardı etmesine yol açar.

Changelog ve arama motoru görünürlüğü

Herkese açık changelog girdileri ürün ve özellik aramalarında bulunabilir; görünürlük garantisi yoktur. İndekslenmesini istediğiniz sayfalarda erişim, robots ve canonical durumunu kontrol edin. Google JavaScript içeriğini işleyebilir; buna rağmen engellenen kaynaklar ve render hataları içeriği görünmez bırakabilir. Statik veya sunucuda oluşturulan içerik bu bağımlılığı azaltabilir.

Her girdiden ilgili yardım belgesine ve özelliğin anlatıldığı sayfaya açıklayıcı bağlantılar verin. Girdinin kalıcı adresi, paylaşım ve destek yanıtlarında işe yarar. SEO çalışmasında arama görünürlüğü ile kullanıcıya güncel bilgi sunma amacı birlikte değerlendirilebilir. İçeriği çoğaltmak için önemsiz güncellemelerden ayrı arama sayfaları üretmeyin.

Girdi sayısı arttıkça sayfa yapısı

Yüzlerce girdiye ulaşan bir changelog'u tek sayfada tutmak, yükleme ve okunabilirlik açısından sorun yaratır. Sayfalamaya ya da yıl bazlı arşive geçin; en yeni girdilerin olduğu sayfa, ana changelog adresi olarak kalmalıdır. Arşiv sayfalarının bağlantılarını ana sayfadan erişilebilir tutun; yalnız arşive giden ayrı bir yol kullanıcının keşfini zorlaştırır.

Kontrol listesi: changelog'u yayına almadan önce

SaaS ürününüzün güncelleme sayfasını ilk gerçek sürümle birlikte deneyin. Yayın kabulünde şu soruları yanıtlayın.

• Girdi formatını (tarih/sürüm, tür etiketi, başlık, açıklama) tanımlayın ve tutarlı uygulayın.
• Değişiklik türlerini ayrı etiketlerle gösterin.
• Bilinen sorunların sürüm ve çözüm durumunun izlenebildiğini doğrulayın.
• Girdi hazırlama adımını sürüm çıkarma akışına ekleyin.
• Yazan, onaylayan ve yayınlayan kişileri tanımlayın.
• Kritik düzeltmeler için sürüm döngüsünden bağımsız yayın yolu belirleyin.
• Herkese açık girdilerin indekslenme tercihini ve teknik erişimini kontrol edin.
• Girdiler arasında ilgili dokümana bağlantı verin.
• Girdi sayısı arttığında sayfalama ya da arşiv planını baştan belirleyin.
• Yayın sonrası hangi kanallarda duyurulacağını girdiye göre seçin.

Sonuç

Güncelleme sayfası, sürüm notunu hazırlama ve yayımlama sorumluluğu belli olduğunda sürdürülebilir olur. Kullanıcıya değişen davranışı, gerekli işlemi ve ilgili belgeyi gösterin. Eski sürüm bilgilerini ve çözüm durumlarını koruyun; duyurunun gerçek erişim durumuyla uyuştuğunu her yayında kontrol edin.