There is a newer version available: Čeština 1.1.0

Udržuj Changelog

Nenech své kamarády házet do CHANGELOGů™ git logy.

Version 0.3.0

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.

# 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 smyslem changelogu?

Usnadnit uživatelům a přispěvatelům přesné zobrazení podstatných změn, které byly provedeny mezi jednotlivými vydáními (verzemi) daného projektu.

Proč by mi na tom mělo záležet?

Protože softwarové nástroje jsou pro lidi. Pokud ti na tom nezáleží, tak proč přispíváš do open source projektů? Určitě musí být v tvém úžasném malém mozku alespoň jádro (haha!) ochoty.

Bavil jsem se s Adamem Stacoviakem a Jerodem Santem na podcastu The Changelog (název sedí, co?) o tom proč by na tom mělo vedoucím a přispěvatelům projektů záležet a o tom jaká motivace je za tímto projektem. Jestli máš chvilku času (1:06), stojí to za poslech.

Co dělá changelog dobrým?

Výborná otázka, díky za ni.

Dobrý changelog se drří těchto principů:

Je psaný pro lidi, ne pro stroje, takže čitelnost je zásadní.
Dá se v něm jednoduše odkázat na libovolnou sekci (proto raději Markdown než plain text).
Jedna pod-sekce za verzi.
Seznam vydání ve zpětně-chronologickém pořadí (nejnovější navrchu).
Psaní všech dat ve formátu RRRR-MM-DD. (Příklad: 2012-06-02 pro 2. červen 2012.) Je to mezinárodní, rozumné a nezávislé na jazyce.
Explicitní uvedení toho, zda projekt dodržuje Semantické Verzování.
Každá verze by měla:
- Uvádět datum vydání ve výše uvedeném formátu.
- Seskupovat změny tak, aby popisovaly dopad na projekt, a to následovně:
- Added pro nové funkce.
- Changed pro změny v aktuálním fungování.
- Deprecated pro dříve stabilní funkce, které budou odstraněny v novějších vydáních a nejsou podporovány.
- Removed pro funkce odstraněné v daném vydání.
- Fixed pro opravené chyby.
- Security pro navržení aktualizace uživatelům v případě bezpečnostních problémů.

Jak mohu vyžadovanou snahu snížit na minimum?

Vždycky měj nahoře sekci "Unreleased", ve které budou schromažďovány všechny změny.

To plní hned dva účely:

Lidé uvidí, jaké změny mohou očekávat v následujících vydáních
V momentu vydání stačí změnit "Unreleased" na číslo verze a přidat nový nadpis "Unreleased" na vrch dokumentu.

Co zaručeně rozbrečí jednorožce?

Dobrá… Tak si to povíme.

Zkopírování diffu commit logů. To prostě nedělej, nikomu to nepomůže.
Nezdůraznění dále nepodporovaných funcí. Když lidé aktualizují na novou verzi, mělo by jim být bolestivě jasné, že se něco rozbije.
Data v regionálních formátech. V USA píšou lidé nejdříve měsíc ("06-02-2012" pro 2. června 2012, což nedává vůbec žádný smysl), zatímco mnoho lidí ve zbytku světa píše roboticky vypadající verzi "2 June 2012", ale vyslovují to jinak. "2012-06-02" je logicky napsané od největšího po nejmenší celek, nepřekrývá se nesrozumitelně s jinými fomáty data a je to ISO standard. Proto je to doporučovaný formát dat pro changelogy.

To ale není všechno. Pomoz mi sbírat jednorožčí slzy tím že otevřeš issue nebo pull request.

Existuje pro formát changelogů nějaký standard?

Bohužel ne. Klid. Vím, že se zuřivě snažíš najít ten odkaz na GNU návod jakým stylem psát changelog, nebo onen dvouodstavcový GNU NEWS soubor, který si říká "směrnice". Zmíněný GNU návod je sice hezký začátek, ale je smutně naivní. Být naivní není nic špatného, ale když lidé potřebují radu, málokdy to někomu pomůže. Obzvlášť, když existuje tolik situací a okrajových případů, se kterými se musí člověk nějak poprat.

Tento projekt obsahuje něco, co se doufám jednou stane lepší konvencí pro CHANGELOGy. Nemyslím si, že je momentální stav dostatečně dobrý, a jsem toho názoru, že jsme jako komunita schopni vymyslet lepší konvence, pokud se budeme snažit vybrat ty nejlepší praktiky z doopravdových softwarových projektů. Porozhlédněte se a mějte na paměti, že diskuse a návrhy na zlepšení jsou vítány!

Jak by se měl changelog jmenovat?

Inu, pokud jste to už nepoznali z příkladu výše, CHANGELOG.md je zatím ta nejlepší konvence.

Některé projekty používají HISTORY.txt, HISTORY.md, History.md, NEWS.txt, NEWS.md, News.txt, RELEASES.txt, RELEASE.md, releases.md, apod.

Je v tom binec. Všecha tato jména jen komplikují život lidem, kteří se ten dokument snaží najít.

Proč lidé jednoduše nepoužívají `git log` diff?

Protože diffy logů jsou plné šumu — přirozeně. Nebyly by vyhovujícím changelogem ani v hypotetickém projektu vedeném dokonalými lidmi, kteří nikdy nedělají překlepy, nikdy nezapomínají commitnout nové soubory a nikdy jim neunikne ani ta nejmenší část refactoringu. Cílem commitu je dokumentovat jeden miniaturní krok při procesu, ve kterém se kód vyvíjí z jedné podoby do druhé. Cílem changelogu je dokumentovat podstatné změny mezi těmito podobami.

Stějně jako je rozdíl mezi dobrými komentáři a samotným kódem, je také rozdíl mezi changelogem a commitlogem: jeden říká proč a druhý jak.

Mohou být changelogy automaticky parsované?

Je to složité, jelikož se lidé uchylují k nejrůznějším formátům a názvům souborů.

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

Proč používáš jednou "CHANGELOG" a jindy "changelog"?

"CHANGELOG" je název samotného souboru. Je to třichu křiklavé, ale to už je historická konvence, kterou se řídí mnoho open source projektů. Příklady podobných souborů mohou být README, LICENSE a CONTRIBUTING.

Název psaný kapitálkami (díky kterému se ve starých operačních systémech soubory držely na nejvyšších pozicích) je používán za účelem upoutání pozornosti. Vzhledem k tomu, že se jedná o důležitá metadata o projektu a mohla by být užitečná pro kohokoliv, kdo ho chce používat nebo do něho přispívat, podobně open source projektovým odznakům.

Když mluvím o "changelogu", myslím tím funkci tohoto souboru: logování změn.

Jak potom vypadají ta vydání, která byla zpětně stažena?

Zpětně 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ěli takto:

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

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

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

Jasně. 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íš, že v poznámkách k verzi ve tvém projektu není zmíněna změna, která něco mohla rozbít. V tom případě jě samozřejmě důležité, aby byl changelog aktualizován.

Jak mohu přidat ruku k dílu?

Tento dokument není čistá pravda; je to můj názor, nad kterým jsem opatrně uvažoval, v kombinaci s informacemi a příklady, které se mi podařilo získat. I přesto, že uvádím vlastní CHANGELOG v repozitáři na GitHubu, naschvál jsem nevytvořil náležité vydání nebo jasný seznam pravidel, kterými se někdo má řídit (jako to například udělali na SemVer.org).

Je tomu tak proto, že chci aby komunita došla ke společné shodě. Já sám jsem toho názoru, že diskuse je důležitou součástí finálního výsledku.

Takže prosím přispějte svou trochou do mlýna.