There is a newer version available: Türkçe 1.1.0

Değişiklik kaydı tutun

Arkadaşlarınızın, git kayıtlarını CHANGELOG dosyalarına yığmasını engelleyin

Version 0.3.0

Nedir bu değişiklik kayıtları?

Değişiklik kayıtları bir proje için özel olarak hazırlanmış, tarihsel sıralamayla sıralanmış, önemli değişikliklerin bir bütünüdür.

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

### Added

- v1.1 Brazilian Portuguese translation.
- v1.1 German Translation
- v1.1 Spanish translation.
- v1.1 Italian translation.
- v1.1 Polish translation.
- v1.1 Ukrainian translation.

### Changed

- Use frontmatter title & description in each language version template
- Replace broken OpenGraph image with an appropriately-sized Keep a Changelog 
  image that will render properly (although in English for all languages)
- Fix OpenGraph title & description for all languages so the title and 
description when links are shared are language-appropriate

### Removed

- Trademark sign previously shown after the project description in version 
0.3.0

## [1.1.1] - 2023-03-05

### Added

- Arabic translation (#444).
- v1.1 French translation.
- v1.1 Dutch translation (#371).
- v1.1 Russian translation (#410).
- v1.1 Japanese translation (#363).
- v1.1 Norwegian Bokmål translation (#383).
- v1.1 "Inconsistent Changes" Turkish translation (#347).
- Default to most recent versions available for each languages.
- Display count of available translations (26 to date!).
- Centralize all links into `/data/links.json` so they can be updated easily.

### Fixed

- Improve French translation (#377).
- Improve id-ID translation (#416).
- Improve Persian translation (#457).
- Improve Russian translation (#408).
- Improve Swedish title (#419).
- Improve zh-CN translation (#359).
- Improve French translation (#357).
- Improve zh-TW translation (#360, #355).
- Improve Spanish (es-ES) transltion (#362).
- Foldout menu in Dutch translation (#371).
- Missing periods at the end of each change (#451).
- Fix missing logo in 1.1 pages.
- Display notice when translation isn't for most recent version.
- Various broken links, page versions, and indentations.

### Changed

- Upgrade dependencies: Ruby 3.2.1, Middleman, etc.

### Removed

- Unused normalize.css file.
- Identical links assigned in each translation file.
- Duplicate index file for the english version.

## [1.1.0] - 2019-02-15

### Added

- Danish translation (#297).
- Georgian translation from (#337).
- Changelog inconsistency section in Bad Practices.

### Fixed

- Italian translation (#332).
- Indonesian translation (#336).

## [1.0.0] - 2017-06-20

### Added

- New visual identity by [@tylerfortune8](https://github.com/tylerfortune8).
- Version navigation.
- Links to latest released version in previous versions.
- "Why keep a changelog?" section.
- "Who needs a changelog?" section.
- "How do I make a changelog?" section.
- "Frequently Asked Questions" section.
- New "Guiding Principles" sub-section to "How do I make a changelog?".
- Simplified and Traditional Chinese translations from [@tianshuo](https://github.com/tianshuo).
- German translation from [@mpbzh](https://github.com/mpbzh) & [@Art4](https://github.com/Art4).
- Italian translation from [@azkidenz](https://github.com/azkidenz).
- Swedish translation from [@magol](https://github.com/magol).
- Turkish translation from [@emreerkan](https://github.com/emreerkan).
- French translation from [@zapashcanon](https://github.com/zapashcanon).
- Brazilian Portuguese translation from [@Webysther](https://github.com/Webysther).
- Polish translation from [@amielucha](https://github.com/amielucha) & [@m-aciek](https://github.com/m-aciek).
- Russian translation from [@aishek](https://github.com/aishek).
- Czech translation from [@h4vry](https://github.com/h4vry).
- Slovak translation from [@jkostolansky](https://github.com/jkostolansky).
- Korean translation from [@pierceh89](https://github.com/pierceh89).
- Croatian translation from [@porx](https://github.com/porx).
- Persian translation from [@Hameds](https://github.com/Hameds).
- Ukrainian translation from [@osadchyi-s](https://github.com/osadchyi-s).

### Changed

- Start using "changelog" over "change log" since it's the common usage.
- Start versioning based on the current English version at 0.3.0 to help
  translation authors keep things up-to-date.
- Rewrite "What makes unicorns cry?" section.
- Rewrite "Ignoring Deprecations" sub-section to clarify the ideal
  scenario.
- Improve "Commit log diffs" sub-section to further argument against
  them.
- Merge "Why can’t people just use a git log diff?" with "Commit log
  diffs".
- Fix typos in Simplified Chinese and Traditional Chinese translations.
- Fix typos in Brazilian Portuguese translation.
- Fix typos in Turkish translation.
- Fix typos in Czech translation.
- Fix typos in Swedish translation.
- Improve phrasing in French translation.
- Fix phrasing and spelling in German translation.

### Removed

- Section about "changelog" vs "CHANGELOG".

## [0.3.0] - 2015-12-03

### Added

- RU translation from [@aishek](https://github.com/aishek).
- pt-BR translation from [@tallesl](https://github.com/tallesl).
- es-ES translation from [@ZeliosAriex](https://github.com/ZeliosAriex).

## [0.2.0] - 2015-10-06

### Changed

- Remove exclusionary mentions of "open source" since this project can
  benefit both "open" and "closed" source projects equally.

## [0.1.0] - 2015-10-06

### Added

- Answer "Should you ever rewrite a change log?".

### Changed

- Improve argument against commit logs.
- Start following [SemVer](https://semver.org) properly.

## [0.0.8] - 2015-02-17

### Changed

- Update year to match in every README example.
- Reluctantly stop making fun of Brits only, since most of the world
  writes dates in a strange way.

### Fixed

- Fix typos in recent README changes.
- Update outdated unreleased diff link.

## [0.0.7] - 2015-02-16

### Added

- Link, and make it obvious that date format is ISO 8601.

### Changed

- Clarified the section on "Is there a standard change log format?".

### Fixed

- Fix Markdown links to tag comparison URL with footnote-style links.

## [0.0.6] - 2014-12-12

### Added

- README section on "yanked" releases.

## [0.0.5] - 2014-08-09

### Added

- Markdown links to version tags on release headings.
- Unreleased section to gather unreleased changes and encourage note
  keeping prior to releases.

## [0.0.4] - 2014-08-09

### Added

- Better explanation of the difference between the file ("CHANGELOG")
  and its function "the change log".

### Changed

- Refer to a "change log" instead of a "CHANGELOG" throughout the site
  to differentiate between the file and the purpose of the file — the
  logging of changes.

### Removed

- Remove empty sections from CHANGELOG, they occupy too much space and
  create too much noise in the file. People will have to assume that the
  missing sections were intentionally left out because they contained no
  notable changes.

## [0.0.3] - 2014-08-09

### Added

- "Why should I care?" section mentioning The Changelog podcast.

## [0.0.2] - 2014-07-10

### Added

- Explanation of the recommended reverse chronological release ordering.

## [0.0.1] - 2014-05-31

### Added

- This CHANGELOG file to hopefully serve as an evolving example of a
  standardized open source project CHANGELOG.
- CNAME file to enable GitHub Pages custom domain.
- README now contains answers to common questions about CHANGELOGs.
- Good examples and basic guidelines, including proper date formatting.
- Counter-examples: "What makes unicorns cry?".

[unreleased]: https://github.com/olivierlacan/keep-a-changelog/compare/v1.1.1...HEAD
[1.1.1]: https://github.com/olivierlacan/keep-a-changelog/compare/v1.1.0...v1.1.1
[1.1.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v1.0.0...v1.1.0
[1.0.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.3.0...v1.0.0
[0.3.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.2.0...v0.3.0
[0.2.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.1.0...v0.2.0
[0.1.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.8...v0.1.0
[0.0.8]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.7...v0.0.8
[0.0.7]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.6...v0.0.7
[0.0.6]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.5...v0.0.6
[0.0.5]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.4...v0.0.5
[0.0.4]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.3...v0.0.4
[0.0.3]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.2...v0.0.3
[0.0.2]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.1...v0.0.2
[0.0.1]: https://github.com/olivierlacan/keep-a-changelog/releases/tag/v0.0.1

Değişikliklerin kayıtlarını tutmanın anlamı ne?

Bir projenin kullanıcılarının ya da katılımcılarının, dağıtımlar (ya da sürümler) arasındaki tam olarak hangi önemli değişikliklerin olduğunu takip edebilmelerini sağlar.

Neden umrumda olsun ki?

Çünkü yazılım paketleri insanlar içindir. Eğer umrunuzda değilse neden açık kaynağa katkıda bulunuyorsunuz ki? Mutlaka sevimli beyninizin bir yerlerinde bunu önemseyen bir çekirdek (a-ha!) vardır.

Adam Stacoviak ve Jerod Santo ile Changelog Podcast'inde (uyuyor, değil mi?) neden geliştiricilerin ve katılımcıların umrunda olması gerektiğini ve bu projenin arkasındaki motivasyonu konuştuk. Eğer vaktiniz varsa (1:06) iyi bir söyleşi oldu.

Bir değişiklik kaydını iyi yapan nedir?

Bunu sorduğunuza sevindim.

İyi bir değişiklik kaydı şu prensiplere bağlıdır:

İnsanlar için yapılmıştır, makineler için değil, yani okunabilirliği kritiktir.
Kolayca bölümler arası bağlantı kurulabilmelidir. (Bu yüzden yalın metin yerine markdown)
Her sürüm için bir alt bölüm içermelidir.
Dağıtımları tersine tarih sırası ile listemelidir. (En yeni en üstte)
Tüm tarihler YYYY-AA-GG biçiminde olmalıdır. (Örneğin 2 Haziran 2012 için 2012-06-02) Uluslararasıdır, anlamlıdır, ve lisan bağımsızdır.
Anlamsal sürümlemenin desteklenip desteklenmediğini özellikle belirtilmelidir.
Her sürümde olması gerekenler:
- Üstteki biçimde dağıtım tarihi.
- Projeye etkileri bakımından değişikliklerin gruplanması, şöyle ki:
- Eklendi: yeni özellikler için,
- Değişti: var olan beceriler değiştiyse,
- Rafa kalktı: gelecekte yok olacak var olan beceriler,
- Kaldırıldı: bu sürümde kaldırılan, daha önce rafa kaldırılmış olan beceriler,
- Düzeltildi: ayıklanmış hatalar,
- Güvenlik: açıkları kapatabilmeleri için kullanıcıları bilgilendirin.

Gerekli çabayı nasıl en aza indirebilirim?

Her zaman en üstte değişiklikleri takip ettiğiniz bir "Yayımlanmadı" bölümü olsun.

Bu, iki amaca hizmet eder:

İnsanlar gelecek sürümlerde karşılarına ne gibi değişiklikler çıkacağını görebilirler
Dağıtım zamanı geldiğinde "Yayımlanmadı" başlığını sürüm numarası ile değişitip tepeye yeni bir "Yayımlanmadı" bölümü eklemeniz yeterli.

Tek boynuzlu atları ağlatan ne?

Peki… Gelelim sadede.

Commit kayıtlarının farkını yüklemek. Sakın bunu yapmayın, kimseye yardım etmiyorsunuz.
Rafa kaldırılanları ön plana çıkarmamak. Kullanıcılar için bir sürümden diğerine yükseltme yaptıklarında neyin bozulabileceği apaçık ortada olmalı.
Bölgesel biçimlenmiş tarihler. ABD'de insanlar ay bilgisini önce kullanıyor ("06-02-2012" demek 2 Haziran 2012 demek yani, ki tamamen saçma), diğer taraftan dünyanın bir çok bölgesinde "2 Haziran 2012" gibi robotik bir yapı kullanıp farklı şekilde dile getiriyor. "2012-06-02" hem mantıksal olarak en büyüğünden en küçüğüne çalışıyor, hem de diğer tarih biçimleriyle çakışmıyor. Aynı zamanda ISO standardında. Bu yüzden değişiklik kayıtları için önerilen tarih biçimidir.

Dahası da var. Bu tek boynuzlu at gözyaşlarını toplamak için bir başlık açın ya da bir çekme isteği (pull request) gönderin.

Standart bir değişiklik kaydı biçimi var mı?

Ne yazık ki hayır. Sakin olun. Biliyorum, şu an alelacele GNU değişiklik kaydı stil rehberi için bağlantı arıyorsunuz, ya da iki paragraflık GNU NEWS dosyasına bakınıyorsunuz. GNU stil rehberi iyi bir başlangıç fakat üzücü derece naif. Naif olmakta yanlış bir şey yok, fakat insanlar rehberlik aradığında nadiren yardımcı oluyorlar. Özellikle ortada uğraşılacak bir çok durum ve uç örnekler mevcutken.

Bu proje umuyorum ki daha iyi CHANGELOG dosyaları için bir altyapı oluşturacak. Mevcut durumun çok iyi olduğunu düşünmüyorum, ve topluluk olarak, gerçek yazılım projelerinden iyi pratikleri toplayarak bundan daha iyisini yapabiliriz. Lütfen etrafa bir göz gezdirin ve unutmayın gelişme yolunda tartışmalara ve önerilere her zaman açığız!

Değişiklik kayıtlarının dosya ismi ne olmalı?

Eh, üstteki örnekten çıkartamadıysanız eğer, CHANGELOG.md şu ana kadarki en iyi çözüm.

Bazı projeler HISTORY.txt, HISTORY.md, History.md, NEWS.txt, NEWS.md, News.txt, RELEASES.txt, RELEASE.md, releases.md vb de kullanıyor.

Tam bir karmaşa. Tüm bu isimler insanların bu dosyayı bulmasını zorlaştırıyor.

Neden `git log` farkları kullanılmasın?

Çünkü kayıt farkları bir sürü parazit içerir - doğal olarak. Mükemmel insanlar tarafından yürütülen, hiç yazım hatasının yapılmadığı, dosyaların gönderilmesinin hiç unutulmadığı, refaktör yapılmasının atlanmadığı varsayımsal bir projede bile, uygun bir değişiklik kaydı oluşmayacaktır. Dosyaları repoya göndermenin amacı, atomik seviyede kodun bir durumdan diğerine geçişinin sağlanmasıdır. Değişiklik kayıtları ise, bu durumlar arasında önem arz eden değişiklikleri belgelemeyi amaçlıyor.

İyi yorumlar ve kodun kendisi arasındaki fark, aynı şekilde değişiklik kayıtları ve commit kayıtları arasındaki gibidir: biri neden olduğunu, diğeri nasıl olduğunu açıklar.

Değişiklik kayıtları otomatik olarak toplanabilir mi?

Zor, çünkü insanlar bir çok farklı biçim ve dosya isimleri kullanıyorlar.

Vandamme, Gemnasium ekibi tarafından oluşturulmuş bir Ruby Gem'idir ve bir çok (hepsini değil) açık kaynaklı projenin değişiklik kayıtlarını ayrıştırabiliyor.

Neden arada bir "CHANGELOG" ve arada bir "değişiklik kaydı" yazıyorsun?

"CHANGELOG" dosyanın ismi. Biraz fazla şaşalı ama bir çok açık kaynak kodlu proje tarafından uygulanan tarihi bir gelenek. Benzer dosyalar da var; README, LICENSE, ve CONTRIBUTING.

Büyük harfle isimlendirme (eski işletim sistemlerinde dosyaların tepede gözükmelerini sağlardı) dikkat çekmek için. Proje hakkında önemli meta verileri içerdikleri için, kullanmak ya da katkıda bulunmak isteyen herkesin işine yarar, tıpkı açık kaynaklı proje rozetleri gibi.

"Değişiklik kaydı"ndan bahsettiğim zamanlar bu dosyanın işlevinden bahsediyorum: Değişiklikleri kaydetmek.

Peki ya Geri çekilen dağıtımlar?

Geri çekilen dağıtımlar, önemli hatalar ya da güvenlik sebepleri nedeniyle yayından geri çekilen sürümlerdir. Genelde bu sürümler değişiklik kayıtlarında görüntülenmezler. Görünmeliler. Tam da şu şekilde görünmeliler:

## 0.0.5 - 2014-12-13 [GERİ ÇEKİLDİ]

[GERİ ÇEKİLDİ] etiketi belirli bir sebepten büyük harf. İnsanların bunu fark etmeleri çok önemli. Ayrıca köşeli parantezler ile çevrelenmiş olması programatik olarak da ayrıştırılabilmesine olanak sağlıyor.

Değişiklik kayıtlarınızı tekrar yazmalı mısınız?

Tabii ki. Her zaman değişiklik kayıtlarını geliştirmek için iyi sebepler vardır. Düzenli olarak açık kaynaklı projelerde bakım yapılmayan değişiklik kayıtları için çekme istekleri yapıyorum.

Ayrıca bir sürümdeki notların arasında önemli bir değişiklikten bahsetmeyi unutmuş olduğunuzu fark edebilirsiniz. Değişiklik kayıtlarınızı bu bilgi ışığında güncellemeniz gerektiği gün gibi ortada.

Nasıl katkıda bulunabilirim?

Bu belge doğrunun kendisi değil; benim hesaplı görüşlerimdir. Beraberinde toparlamış olduğum bilgiler ve örnekler bulunur. GitHub reposunda güncel bir CHANGELOG sağlıyor olsam da, özellikle bir sürüm ya da (SemVer.org benzeri) takip edilecek kurallar oluşturmadım.

Bunu istememin sebebi topluluğun ortak bir paydada buluşmasını istememdir. İnanıyorum ki tartışmanın kendisi de sonucu kadar önemli.

Yani lütfen, siz de katılın.