Udržuj Changelog

Nenech své kamarády sypat git logy do changelogů.

Verze 1.1.0 
# 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

Co je to changelog?

Changelog je soubor, který obsahuje organizovaný, chronologicky seřazený seznam podstatných změn pro každou verzi daného projektu.

Proč udržovat changelog?

Aby uživatelé a přispěvatelé přesně věděli, jaké podstatné změny byly provedeny mezi jednotlivými vydáními (verzemi) daného projektu.

Kdo potřebuje changelog?

Lidé. Ať už se jedná o spotřebitele nebo vývojáře, koncoví uživatelé softwaru jsou lidská stvoření, kterým záleží na tom, co software obsahuje. Když se daný software změní, lidé chtějí vědět proč a jak.

Jak vytvořit dobrý changelog?

Hlavní zásady

  • Changelogy jsou pro lidi, ne pro stroje.
  • Changelog by měl obsahovat záznam pro každou verzi.
  • Stejné typy změn by měly být seskupené.
  • Měla by existovat možnost odkazovat na jednotlivé verze a sekce.
  • Poslední verze je na prvním místě.
  • U každé verze je poznamenáno datum jejího vydání.
  • Zmiňte, zda se držíte Sémantického verzování

Typy změn

  • Added pro nové funkce.
  • Changed pro změny v existující funkcionalitě.
  • Deprecated pro funkce, které budou brzy odstraněny.
  • Removed pro odstraněné funkce.
  • Fixed pro opravy chyb.
  • Security v případě bezpečnostních zranitelností.

Jak minimalizovat úsilí potřebné k udržování changelogu?

Udržováním Unreleased sekce na začátku souboru pro zaznamenávání nadcházejících změn.

To plní hned dva účely:

  • Lidé uvidí, jaké změny mohou očekávat v následujících vydáních
  • V čas vydání stačí přesunout změny z Unreleased sekce do sekce nového vydání.

Mohou být changelogy špatné?

Ano. Zde je několik případů, kdy mohou být opakem užitečného.

Diffy z commit logu

Používání diffů z commit logu jako changelogu je špatný nápad: jsou plné šumu. Obsahují věci jako merge commity, commity s nejasnými nadpisy, změny v dokumentaci, atd.

Účelem commitu je zdokumentovat krok v evoluci zdrojového kódu. Některé projekty commity pročišťují, jiné zas ne.

Účelem záznamu v changelogu je zdokumentovat podstatné změny, často napříč několika commity, a jasně je sdělit koncovým uživatelům.

Ignorování odstraněných funkcí

Když lidé upgradují z jedné verze na druhou, mělo by jim být bolestně jasné, když se něco rozbije. Mělo by být možné nejprve upgradovat na verzi, která oznámí, jaké funkce budou odstraněny, dané funkce odstranit a poté upgradovat na verzi, kde jsou zmíněné funkce již odstraněny.

Když už nic jiného, je dobré alespoň vypsat odstraněné funkce a změny, které něco rozbíjí, do changelogu.

Matoucí data

Regionální formáty dat se liší napříč světem a je často složité najít formát, který je přátelský a intuitivní pro všechny. Výhodou dat formátovaných jako 2017-07-17 je pořadí jednotek od největší po nejmenší: rok, měsíc a den. Tento formát se navíc nepřekrývá s jinými, narozdíl od některých regionálních formátů, které prohazují pozici měsíce a dne. Díky těmto důvodům, a také faktu, že je tento formát ISO standard, je doporučeným formátem pro záznamy v changelogu.

Nekonzistentní změny

Changelog, který uvádí pouze některé změny, může být stejně nebezpečný jako absence changelogu. I když mnoho změn nemusí být relevantních - například odstranění jednoho prázdného znaku nemusí být nutně uvedeno – všechny důležité změny by měly být uvedeny v changelogu. Nedůsledným uplatňováním změn si mohou vaši uživatelé mylně myslet, že changelog je jediný správný zdroj. Mělo by tak být. S velkou mocí přichází velká zodpovědnost - mít dobrý changelog znamená mít ho neustále aktualizovaný.

Často kladené otázky

Existuje pro formát changelogu nějaký standard?

Ne. Je tu GNU stylová příručka pro changelog, nebo ta dvouodstavcová GNU "směrnice" pro NEWS soubor. Ani jedno však není vhodné či dostačující.

Tento projekt má za cíl být lepší konvencí pro changelog. Pochází z pozorování osvědčených postupů v open source komunitě a jejich shromažďování.

Zdravá kritika, diskuse a návrhy na zlepšení jsou vítány.

Jak by se soubor s changelogem měl jmenovat?

Pojmenujte ho CHANGELOG.md. Některé projekty používají HISTORY, NEWS nebo RELEASES.

Zatímco je snadné si myslet, že na názvu souboru vašeho changelogu až tak nezáleží, proč koncovým uživatelům ztěžovat hledání významných změn?

A co GitHub Releases?

Je to skvělá iniciativa. Služba Releases může být použita na proměnu obyčejných git tagů (například tag s názvem v1.0.0) na bohaté poznámky k vydání manuálním přidáním daných poznámek, nebo může pullnout zprávy z anotovaných git tagů a udělat poznámky k vydání z nich.

GitHub Releases však vytvářejí nepřenosný changelog, který může být zobrazen uživatelům jen v kontextu GitHubu. Je možné je udělat velmi podobné formátu projektu Udržuj Changelog, ale to má tendenci být trochu náročnější.

Aktuální verze GitHub Releases také pravděpodobně není příliš objevitelná koncovými uživateli, narozdíl od typických souborů s názvy psanými velkými písmeny (README, CONTRIBUTING, atd.). Další menší problém je, že Releases aktuálně nenabízí možnost odkazovat na commit logy mezi jednotlivými vydáními.

Mohou changelogy být automaticky parsovány?

Je to složité, protože lidé používají mnoho rozdílných formátů a názvů souborů.

Vandamme je Ruby gem vytvořený týmem Gemnasium, který parsuje mnoho (ale ne všechny) changelogy open source projektů.

A co zpětně stažená vydání?

Stažená vydání jsou verze, které musely být zpětně odebrány kvůli vážné chybě nebo bezpečnostním rizikům. Tyto verze se často v changelogu ani neobjevují, ale měly by. Zobrazovat by se měly takto:

## [0.0.5] - 2014-12-13 [YANKED]

Tag [YANKED] je křiklavý naschvál. Je důležité, aby si ho lidé všimli. Díky tomu, že je v hranatých závorkách, je také jednodušší ho parsovat programem.

Měl by se changelog někdy přepisovat?

Jistě. Vždy se najde dobrý důvod pro zlepšení changelogu. Sám často otevírám pull requesty pro přidání chybějících vydání v open source projektech s neudržovanými changelogy.

Je také možné, že zjistíte, že v poznámkách k verzi ve vašem projektu není zmíněna změna, která něco rozbila. V tom případě je samozřejmě důležité, aby byl changelog aktualizován.

Jak mohu přispět?

Tento dokument není čistá pravda; je to můj pečlivě zvážený názor, společně s informacemi a příklady, které jsem shromáždil.

Je tomu tak proto, že chci aby naše komunita došla ke společné shodě. Věřím, že diskuse je stejně důležitá jako konečný výsledek.

Takže prosím, přiložte ruku k dílu.

Rozhovory

Zúčastnil jsem se podcastu The Changelog, abych promluvil o tom, proč by se správci projektů a přispěvatelé měli starat o changelogy a také o motivaci za tímto projektem.