There is a newer version available: Italiano 1.1.0

Mantenere un CHANGELOG

Non lasciate che i vostri amici copino e incollino i git log nei CHANGELOG

Version 0.3.0

Cos'è un change log?

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

# 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

A cosa serve un change log?

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

Perché dovrebbe importarmi?

Perché gli strumenti software sono fatti per le persone. Se non ti importa, perché contribuisci all'open source? Di certo ci deve essere un "kernel" (ha!) di interesse da qualche parte in quel tuo amorevole cervello.

Nel podcast "The Changelog" con Adam Stacoviak e Jerod Santo (titolo appropriato, vero?) ho parlato del perché maintainer e contribuenti dovrebbero esserne interessati, e delle motivazioni dietro a questo progetto. Se avete tempo (1:06), vale la pena ascoltarlo.

Come si può fare un buon change log?

Sono contento che tu l'abbia chiesto.

Un buon change log è guidato dai seguenti principi:

È fatto per umani, non macchine, quindi la leggibilità è cruciale.
Facile da linkare ad altre sezioni (da cui il Markdown invece che testo normale).
Una sotto-sezione per ogni versione.
Elenca le release in ordine cronologico inverso (quelle più recenti all'inizio).
Scrive tutte le date nel formato YYYY-MM-DD. (Esempio: 2012-06-02 sta per 2 Giugno 2012). È internazionale, sensato, e indipendente dalla lingua.
Dichiara esplicitamente se il progetto segue il Semantic Versioning.
Ogni versione dovrebbe:
- Elencare la sua data di rilascio nel formato sopra specificato.
- Raggruppare le modifiche per descrivere il loro impatto sul progetto, come segue:
- Added per le nuove funzionalità.
- Changed per le modifiche a funzionalità esistenti.
- Deprecated per vecchie feature stabili che verranno rimosse nelle future release.
- Removed per funzionalità precedentemente deprecate rimosse in questa release.
- Fixed per tutti i bug fix.
- Security per invitare gli utilizzatori ad aggiornare in caso di vulnerabilità.

Come posso minimizzare lo sforzo richiesto?

Usa sempre una sezione "Unreleased" all'inizio per tenere traccia di qualsiasi modifica.

Questo serve per due scopi:

La gente può vedere quali modifiche si può aspettare in future release
Ad una nuova release, si deve solo sostituire "Unreleased" con il numero di versione e aggiungere una nuova sezione "Unreleased" all'inizio.

Cosa fa piangere gli unicorni?

Bene...vediamo un po'.

Copia&incolla un diff di commig log. Non fatelo, così non aiutate nessuno.
Non enfatizzare le funzioni deprecate. Quando le persone aggiornano da una versione ad un'altra, dovrebbe essere dolorosamente chiaro quando qualcosa si romperà.
Date in formati specifici per regione. Negli Stati Uniti si mette prima il mese nelle date ("06-02-2012" sta per 2 Giugno 2012, che non ha senso), mentre molte persone nel resto del mondo scrivono un robotico "2 June 2012", ma lo pronunciano diversamente. "2012-06-02" funziona con la logica dal più grande al più piccolo, non ha sovrapposizioni ambigue con altri formati di date, ed è uno standard ISO. Per tutti questi motivi, è il formato di date raccomandato per i change log.

C'è di più. Aiutatemi a collezionare queste "lacrime di unicorno" aprendo una "issue" o una pull request.

Esiste un formato standard per i change log?

Purtroppo no. Calma. So che state furiosamente correndo a cercare quel link alla guida di stile per i change log GNU, o alle linee guida per or il file a due paragrafi GNU NEWS. La guida GNU è un buon punto di partenza, ma è tristemente ingenuo. Non c'è nulla di male nell'essere ingenuo, ma quando le persone cercano una guida, questa caratteristica è raramente d'aiuto. Specialmente se ci sono molte situazioni e casi limite da gestire.

Questo progetto contiene ciò che spero diventerà una migliore convenzione per i file CHANGELOG. Non credo che lo status quo sia sufficientemente buono, e penso che noi, come comunità, possiamo arrivare a convenzioni migliori se tentiamo di estrarre le pratiche migliori da progetti software reali. Vi consiglio di guardarvi intorno e ricordare che ogni discussione e suggerimento per migliorare sono sempre benvenuti!

Come si dovrebbe chiamare il file contenente il change log?

Se non l'avete dedotto dall'esempio qui sopra, CHANGELOG.md è la convenzione migliore finora.

Alcuni progetti usano anche HISTORY.txt, HISTORY.md, History.md, NEWS.txt, NEWS.md, News.txt, RELEASES.txt, RELEASE.md, releases.md, etc.

È un disastro. Tutti questi nomi contribuiscono solo a rendere più difficile trovarlo.

Perché la gente non si limita ad usare diff di `git log`?

Perché i log diff sono pieni di rumore, per loro natura. Non potrebbero creare un change log decente nemmeno in un ipotetico progetto gestito da perfetti umani che non fanno mai errori di digitazione, non dimenticano mai di fare commit dei nuovi file, non dimenticano mai alcuna parte di un refactoring. Lo scopo di un commit è di documentare un passo atomico nel processo di evoluzione del codice da uno stato ad un altro. Lo scopo di un change log è di documentare le differenze degne di nota tra questi stati.

La differenza tra un change log e un commit log è come la differenza tra un buon commento nel codice e il codice stesso: uno descrive il perché, l'altro il come.

Si possono analizzare automaticamente i change log?

È 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 change log di molti (ma non tutti) i progetti open source.

Perché si alterna tra i nomi "CHANGELOG" e "change log"?

"CHANGELOG" è il nome del file. È un po' invadente ma è una convenzione storica seguita da molti progetti open source. Altri esempi di file simili includono README, LICENSE, e CONTRIBUTING.

I nomi in maiuscolo (che su vecchi sistemi operativi erano ordinati per primi) vengono usati per attirare l'attenzione su di essi. Poiché sono metadati importanti relativi al progetto, possono essere utili per chiunque voglia usarlo o contribuire ad esso, un po' come i badge dei progetti open source.

Quando mi riferisco a un "change log", sto parlando della funzione di questo file: registrare le modifiche.

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 change log. Invece dovrebbero esserci, nel seguente modo:

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

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

Si dovrebbe mai modificare un change log?

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

È anche possibile che si scopra di aver dimenticato di annotare una modifica non retro-compatibile nelle note per una versione. Ovviamente è importante aggiornare il change log 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. Anche se fornisco un CHANGELOG reale sul repository GitHub, ho volutamente evitato di creare una release o una chiara lista di regole da seguire (come fa, ad esempio, SemVer.org).

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.