Prowadź Changelog

Nie pozwól swoim znajomym wklejać logów Gita do changelogów.

Wersja 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

Czym jest changelog?

Changelog, inaczej rejestr zmian, to plik zawierający utrzymywaną, uporządkowaną chronologicznie, listę istotnych zmian dla każdej wersji projektu.

Po co prowadzić changelog?

Aby użytkownikom i deweloperom łatwiej było dokładnie zobaczyć, jakie znaczące zmiany zostały wprowadzane w każdym wydaniu (lub wersji) projektu.

Komu potrzebny jest changelog?

Ludziom. Czy to klienci czy deweloperzy, końcowi użytkownicy oprogramowania są istotami ludzkimi, którym nie jest obojętne, co jest w oprogramowaniu. Kiedy oprogramowanie się zmienia, ludzie chcą wiedzieć dlaczego i jak.

Jak zrobić dobry changelog?

Zasady przewodnie

  • Changelogi są dla ludzi, nie maszyn.
  • Każda wersja powinna mieć swój wpis.
  • Jednakowe typy zmian powinny być zgrupowane.
  • Wersje i sekcje powinny być linkowalne.
  • Najnowsza wersja na pierwszym miejscu.
  • Wyszczególniona data wydania każdej wersji.
  • Wzmianka, czy przestrzegacie wersjonowania semantycznego.

Typy zmian

  • Dodane dla nowych funkcjonalności.
  • Zmienione dla zmian w istniejących funkcjonalnościach.
  • Zdezaprobowane dla funkcjonalności wkrótce do usunięcia.
  • Usunięte dla teraz usuwanych funkcjonalności.
  • Naprawione dla jakichkolwiek poprawek błędów.
  • Bezpieczeństwo w przypadku luk w zabezpieczeniach.

Jak mogę zminimalizować wysiłek wkładany w prowadzenie changelogu?

Prowadź sekcję Niewydane na szczycie dokumentu, aby śledzić nadchodzące zmiany.

Ta praktyka ma dwa cele:

  • Ludzie widzą, jakich zmian mogą się spodziewać w nadchodzących wydaniach.
  • W momencie wydania możesz przenieść zmiany z sekcji Niewydane do sekcji nowego wydania.

Czy changelogi mogą być złe?

Tak. Oto kilka sposobów, w jakie mogą być mniej niż użyteczne.

Zmiany w commit logu

Używanie zmian w commit logach jako changelogów jest złym pomysłem: commit logi są pełne szumu: rzeczy takich jak merge commity, commity z niejasnymi tytułami, zmiany w dokumentacji itp.

Zadaniem commita jest udokumentowanie kroku w ewolucji kodu źródłowego. Niektóre projekty porządkują commity, niektóre nie.

Zadaniem wpisu w changelogu jest udokumentowanie zmian godnych odnotowania, często składających się z wielu commitów, aby przedstawić je jasno użytkownikom końcowym.

Ignorowanie dezaprobowań

Gdy ludzie robią upgrade z jednej wersji do drugiej, powinno być bezboleśnie jasne kiedy coś się może zepsuć. Powinno być możliwe upgrade'owanie się do wersji, która wypisuje zdezaprobowania, usunięcie tego, co jest zdezaprobowane, następnie upgrade'owanie się do wersji, w której dezaprobowane funkcjonalności są usuwane.

Jeśli nie robisz nic innego, wypisz w swoim changelogu zdezaprobowania, usunięcia i jakiekolwiek zmiany łamiące zgodność wstecz.

Mylące daty

Regionalne formaty dat różnią się na świecie i często trudno jest znaleźć przyjazny człowiekowi format daty, który wydaje się intuicyjny wszystkim. Zaletą dat sformatowanych tak jak 2017-07-17 jest to, że są one uporządkowane od największych do najmniejszych jednostek: roku, miesiąca i dnia. Ten format również nie nachodzi w niejednoznaczny sposób na inne formaty dat, w przeciwieństwie do niektórych regionalnych formatów, które zamieniają miejsce numerów miesiąca i dnia. Z tych powodów i faktu, że ten format daty jest standardem ISO, wynika rekomendacja tego formatu daty do wpisów w changelogu.

Niespójne zmiany

Changelog, który wspomina tylko o niektórych zmianach, może być równie niebezpieczny jak brak changeloga. Chociaż wiele zmian może nie być istotnych — na przykład usunięcie pojedynczej białej spacji może nie wymagać odnotowania — to wszelkie ważne zmiany powinny być wymienione w changelogu. Poprzez niekonsekwentne stosowanie zmian, Twoi użytkownicy mogą błędnie myśleć, że changelog jest jedynym źródłem prawdy. I tak być powinno. Siła wynika tuaj z odpowiedzialności — posiadanie dobrego changeloga oznacza posiadanie konsekwentnie aktualizowanego changeloga.

Często zadawane pytania

Czy istnieje standardowy format changelogu?

Niezupełnie. Jest przewodnik stylu changelogu GNU, czy dwuparagrafowe „wytyczne” GNU NEWS. Oba dokumenty są nieadekwatne lub niewystarczające.

Ten projekt pretenduje do bycia lepszą konwencją changelogu. Pochodzi z obserwowania i zebrania dobrych praktyk w społeczności open source.

Zdrowa krytyka, dyskusja i sugestie poprawek są mile widziane.

Jak powinien się nazywać plik z changelogiem?

Nazwij go CHANGELOG.md. Niektóre projekty używają HISTORY, NEWS lub RELEASES.

Łatwo jest uznać, że nazwa pliku z changelogiem nie ma większego znaczenia, lecz po co utrudniać swoim użytkownikom końcowym odnajdowanie w sposób konsekwentny istotnych zmian?

Co z GitHub Releases?

To wspaniała inicjatywa. Releases mogą być używane do zmiany prostych tagów Gita (na przykład taga nazwanego v1.0.0) w bogate informacje o wydaniach przez ręczne dodanie informacji lub mogą wyciągać oznaczone message tagów i przekształcać je w informacje.

GitHub Releases tworzą nieprzenośny changelog, który może być prezentowany użytkownikom tylko w kontekście GitHuba. Można go bardzo upodobnić do formatu Prowadź changelog, ale będzie to dość skomplikowane.

Bieżąca wersja wydań GitHub jest też prawdopodobnie nienajłatwiejsza do odnalezienia dla użytkowników końcowych, w przeciwieństwie do plików o nazwach z wielkimi literami (README, CONTRIBUTING itp.). Innym mniejszym brakiem jest to, że interfejs obecnie nie posiada linków do logów commitów pomiędzy każdymi wydaniami.

Czy changelogi mogą być parsowane automatycznie?

To trudne, ponieważ ludzie stosują bardzo różne formaty i nazwy plików.

Vandamme jest gemem Ruby stworzonym przez zespół Gemnasium i który parsuje wiele (ale nie wszystkie) changelogów projektów open source.

Co z wycofanymi wydaniami?

Wydania typu yanked to wersje, które musiały zostać usunięte z powodu poważnego błędu lub problemów z bezpieczeństwem. Często te wersje nie pojawiają się w dziennikach zmian. Powinny. Tak powinieneś je wyświetlać:

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

Etykieta [WYCOFANA] jest celowo zapisana wielkimi literami. Ważne jest, by zwracano na nią uwagę. Jest otoczona nawiasami, więc jest również prostsza do sparsowania przez skrypt.

Czy powinno się kiedykolwiek przerabiać changelog?

Pewnie. Zawsze istnieją dobre powody, by ulepszyć changelog. Regularnie otwieram pull requesty dodające brakujące wydania do open-source'owych projektów z nieutrzymywanymi changelogami.

Może się również zdarzyć, że odkryjesz, iż zapomniałeś udokumentować zmianę zrywającą zgodność wsteczną w notatkach dla wersji. Oczywiście ważne jest, abyś zaktualizował swój changelog w tym przypadku.

Jak mogę wnieść swój wkład?

Ten dokument nie jest obiektywną prawdą; jest moją starannie przemyślaną opinią, z informacjami i przykładami, które zebrałem.

To dlatego, że chcę, aby nasza społeczność osiągnęła konsensus. Wierzę, że dyskusja jest tak samo istotna jak efekt końcowy.

Więc proszę, wtrąć się.

Rozmowy

Byłem na podcaście Changelog, aby porozmawiać dlaczego opiekunowie i kontrybutorzy powinni dbać o changelogi, a także o motywacjach stojących za tym projektem.