Tenere un Changelog

Non lasciare che i tuoi amici facciano copia incolla dei git logs nei changelog.

Versione 1.0.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

Cos'è un changelog?

Un changelog è un file che contiene una lista curata e ordinata cronologicamente delle modifiche degne di nota per ogni versione di un progetto.

Perché tenere un changelog?

Per rendere facile agli utilizzatori e contribuenti vedere con precisione quali modifiche importanti sono state fatte tra ogni release (o versione) del progetto.

Chi ha bisogno di un changelog?

Le persone ne hanno bisogno. Che si tratti di consumatori o di sviluppatori, gli utenti finali sono persone interessate a ciò che avviene in esso. Se il software è cambiato, allora le persone vogliono sapere come e perché.

Come posso fare un buon changelog?

Linee guida

  • I changelog sono per le persone, non per le macchine.
  • Dovrebbe esserci una voce per ogni singola versione.
  • Le modifiche dello stesso tipo dovrebbero essere raggruppate.
  • Versioni e sezioni dovrebbero essere collegabili.
  • L'ultima versione viene per prima.
  • Viene mostrata la data di release di ogni versione.
  • Si dichiara se il progetto segue il Versionamento Semantico.

Tipologie di cambiamenti

  • Added per le nuove funzionalità.
  • Changed per le modifiche a funzionalità esistenti.
  • Deprecated per le funzionalità che saranno rimosse nelle future release.
  • Removed per funzionalità rimosse in questa release.
  • Fixed per tutti i bug fix.
  • Security per invitare gli utilizzatori ad aggiornare in caso di vulnerabilità.

Come posso ridurre gli sforzi necessari a mantenere un changelog?

Tieni una sezione Unreleased in cima al changelog in modo da tenere traccia dei cambiamenti imminenti.

Questo serve per due scopi:

  • Le persone possono vedere quali modifiche si possono aspettare nelle future release.
  • Ad una nuova release, si deve solo spostare i cambiamenti della sezione `"Unreleased"` in una nuova sezione con il corrispettivo numero di versione.

I changelog possono essere cattivi?

Si. Ecco alcuni modi in cui possono essere meno utili.

Commit log diffs

Usare i commit log diffs al posto dei changelog è una brutta idea: contengono solo cose superflue. Cose come i merge commits, i commits con titoli oscuri, le modifiche della documentazione, etc.

Lo scopo di un commit è quello di documentare un passo nell'evoluzione del codice sorgente. Alcuni progetti ripuliscono i commit, altri non lo fanno.

Lo scopo di una voce changelog è quello di documentare le differenze rilevanti, spesso attraverso commit multipli, per comunicarli in modo chiaro agli utenti finali.

Ignorare le deprecazioni

Quando le persone aggiornano da una versione ad un'altra, dovrebbe essere dolorosamente chiaro che qualcosa si romperà. Dovrebbe essere possibile eseguire l'aggiornamento a una versione che elenca le deprecazioni, rimuovere ciò che è deprecato, quindi aggiornare alla versione in cui le deprecazioni diventano rimozioni.

Se non fai nient'altro elenca le deprecazioni, le rimozioni e qualsiasi altro cambiamento nel tuo changelog.

Confusione delle date

I formati di date variano da Paese a Paese e spesso trovare un formato human-friendly che sia intuitivo per tutti è cosa ardua. Il vantaggio delle date formattate come 2017-07-17 è che seguono l'ordine dal maggiore al minore: anno, mese e giorno. Inoltre questo formato non ha sovrapposizioni ambigue con altri formati di date, a differenza di alcuni formati regionali che scambiano la posizione del mese e del giorno. Queste motivazioni e il fatto che questo formato di data è uno standard ISO spiegano perché questo è il formato di date raccomandato per i changelog.

Domande frequenti

Esiste un formato standard per i changelog?

Non esattamente. Esistono le linee guida GNU sullo stile dei changelog, oppure i due lunghi paragrafi nel documento di GNU NEWS denominato "guideline". Entrambe sono inadeguate o insufficienti.

Questo progetto vuole essere una migliore convenzione per i file changelog. Per questo motivo osserviamo le migliori pratiche della comunità open source e le portiamo avanti.

Critiche, discussioni e suggerimenti per migliorare sono ben accetti.

Come si dovrebbe chiamare il file di changelog?

Chiamalo CHANGELOG.md. Alcuni progetti usano anche HISTORY, NEWS o RELEASES.

Risulta facile pensare che il nome del tuo file changelog non sia poi così importante, allora perché non rendere facile la vita ai tuoi utenti, usando sempre lo stesso nome?

Cosa dire delle GitHub Releases?

È una bella iniziativa. Releases può essere usato per rendere semplice i git tags (per esempio il nome del tag v1.0.0) All'interno di note di rilascio ben dettagliate si possono aggiungere le note manualmente oppure è possibile utilizzare i messaggi dei git tag inserendoli dentro le note di rilascio.

GitHub Releases crea un changelog non-portable che può essere solo visualizzato dagli utenti nel contesto di GitHub. È possibile farlo apparire molto simile al formato di Keep a Changelog, tuttavia tende ad essere un po' più complicato.

La versione corrente di GitHub Releases risulta inoltre probabilmente poco rilevante per gli utenti finali, a differenza dei tipici file maiuscoli (README, CONTRIBUTING, etc.). Un altro problema minore è che l'interfaccia non offre attualmente link per la creazione di log tra ciascuna release.

I changelog possono essere analizzati automaticamente?

È difficile, perché le persone usano formati e nomi di file profondamente diversi.

Vandamme è una Ruby gem creata dal team Gemnasium ed è in grado di fare il parsing dei changelog di molti (ma non tutti) i progetti open source.

Cosa sono le release "yanked"?

Le release "yanked" sono versioni che sono state rimosse a causa di bug seri o problemi di sicurezza. Spesso queste versioni non appaiono nei changelog. Invece dovrebbero esserci, nel seguente modo:

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

L'etichetta [YANKED] è in maiuscolo per un motivo. È importante che le persone la notino. Poiché è racchiusa tra parentesi quadre è anche più semplice da riconoscere nel parsing automatico.

Si dovrebbe mai modificare un changelog?

Certo. Ci sono sempre buoni motivi per migliorare un changelog. Io apro regolarmente delle pull request per aggiungere release mancanti ai progetti open source che non mantengono correttamente i changelog.

È anche possibile che si scopra di aver dimenticato di annotare una modifica non retro-compatibile nelle note per una versione. Ovviamente è importante aggiornare il changelog in questo caso.

Come posso contribuire?

Questo documento non è la verità assoluta; è solo la mia attenta opinione, arricchita dalle informazioni ed esempi che ho raccolto.

Questo perché voglio che la nostra comunità raggiunga un consenso. Credo che la discussione sia importante almeno quanto il risultato finale.

Quindi per favore partecipate.

Dialogo

Sono andato a The Changelog podcast per parlare del perché i gestori e i contributori dovrebbero preoccuparsi dei changelog e anche delle motivazioni dietro questo progetto.