mirror of
https://github.com/olivierlacan/keep-a-changelog.git
synced 2025-07-29 16:54:12 +02:00
Fix multiple identation errors
This commit is contained in:
Olivier Lacan
parent
2a0df6b2a9
commit
92db66e139
@ -5,7 +5,6 @@ language: it-IT
|
||||
version: 1.0.0
|
||||
---
|
||||
|
||||
|
||||
- changelog = "https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md"
|
||||
- gemnasium = "https://gemnasium.com/"
|
||||
- gh = "https://github.com/olivierlacan/keep-a-changelog"
|
||||
@ -75,9 +74,9 @@ version: 1.0.0
|
||||
%li
|
||||
L'ultima versione viene prima.
|
||||
%li
|
||||
Viene mostrata la data di release di ogni versione.
|
||||
Viene mostrata la data di release di ogni versione.
|
||||
%li
|
||||
Si dichiara se il progetto segue il #{link_to "Versionamento Semantico", semver}.
|
||||
Si dichiara se il progetto segue il #{link_to "Versionamento Semantico", semver}.
|
||||
|
||||
%a.anchor{ href: "#types", aria_hidden: "true" }
|
||||
%h4#types Tipologie di cambiamenti
|
||||
@ -109,8 +108,8 @@ version: 1.0.0
|
||||
Come posso ridurre gli sforzi necessari a mantenere un changelog?
|
||||
|
||||
%p
|
||||
Tieni una sezione <code>Unreleased</code> in cima al changelog in modo da tenere traccia
|
||||
dei cambiamenti imminenti.
|
||||
Tieni una sezione <code>Unreleased</code> in cima al changelog in
|
||||
modo da tenere traccia dei cambiamenti imminenti.
|
||||
|
||||
%p Questo serve per due scopi:
|
||||
|
||||
@ -118,14 +117,16 @@ version: 1.0.0
|
||||
%li
|
||||
Le persone possono vedere quali modifiche si possono aspettare nelle future release.
|
||||
%li
|
||||
Ad una nuova release, si deve solo spostare i cambiamenti della sezione
|
||||
`"Unreleased"` in una nuova sezione con il suo numero di versione.
|
||||
Ad una nuova release, si deve solo spostare i cambiamenti della sezione
|
||||
`"Unreleased"` in una nuova sezione con il suo numero di versione.
|
||||
|
||||
.bad-practices
|
||||
%h3#bad-practices
|
||||
%a.anchor{ href: "#bad-practices", aria_hidden: "true" }
|
||||
I changelog possono essere cattivi?
|
||||
|
||||
%p Si. Ecco alcuni modi in cui possono essere meno utili.
|
||||
|
||||
%h4#log-diffs
|
||||
%a.anchor{ href: "#log-diffs", aria_hidden: "true" }
|
||||
Commit log diffs
|
||||
@ -212,34 +213,41 @@ version: 1.0.0
|
||||
%h4#github-releases
|
||||
%a.anchor{ href: "#github-releases", aria_hidden: "true" }
|
||||
Cosa dire delle GitHub Releases?
|
||||
|
||||
%p
|
||||
È una bella iniziativa. #{link_to "Releases", ghr} può essere usato
|
||||
per rendere semplice i git tags (per esempio il nome del tag <code>v1.0.0</code>)
|
||||
All'interno di note di rilascio ben dettagliate si possono aggiungere le note manualmente oppure è possibile
|
||||
utilizzare le note dei messaggi dei git tag inserendole dentro nelle note di rilascio.
|
||||
j
|
||||
per rendere semplice i git tags (per esempio il nome del tag
|
||||
<code>v1.0.0</code>) All'interno di note di rilascio ben dettagliate
|
||||
si possono aggiungere le note manualmente oppure è possibile
|
||||
utilizzare le note dei messaggi dei git tag inserendole dentro nelle
|
||||
note di rilascio.
|
||||
|
||||
%p
|
||||
GitHub Releases crea un changelog non-portable che può essere solo
|
||||
visualizzato dagli utenti nel contesto di GitHub. È possibile farlo
|
||||
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.
|
||||
|
||||
%p
|
||||
La versione corrente di GitHub Releases risulta inoltre probabilmente
|
||||
poco rilevante per gli utenti finali, a differenza dei tipici file maiuscoli
|
||||
(<code>README</code>, <code>CONTRIBUTING</code>, etc.). Un altro problema
|
||||
minore è che l'interfaccia non offre attualmente link per la
|
||||
creazione di log tra ciascuna release.
|
||||
La versione corrente di GitHub Releases risulta inoltre
|
||||
probabilmente poco rilevante per gli utenti finali, a differenza dei
|
||||
tipici file maiuscoli (<code>README</code>,
|
||||
<code>CONTRIBUTING</code>, etc.). Un altro problema minore è che
|
||||
l'interfaccia non offre attualmente link per la creazione di log tra
|
||||
ciascuna release.
|
||||
|
||||
%h4#automatic
|
||||
%a.anchor{ href: "#automatic", aria_hidden: "true" }
|
||||
I changelog possono essere analizzati automaticamente?
|
||||
|
||||
%p
|
||||
È difficile, perché le persone usano formati e nomi di file profondamente diversi.
|
||||
È difficile, perché le persone usano formati e nomi di file
|
||||
profondamente diversi.
|
||||
|
||||
%p
|
||||
#{link_to "Vandamme", vandamme} è una Ruby gem
|
||||
creata dal team #{link_to "Gemnasium", gemnasium} ed è in grado di fare il parsing dei
|
||||
change log di molti (ma non tutti) i progetti open source.
|
||||
#{link_to "Vandamme", vandamme} è una Ruby gem creata dal team
|
||||
#{link_to "Gemnasium", gemnasium} ed è in grado di fare il parsing dei
|
||||
change log di molti (ma non tutti) i progetti open source.
|
||||
|
||||
|
||||
%h4#yanked
|
||||
@ -247,17 +255,18 @@ version: 1.0.0
|
||||
Cosa sono le release "yanked"?
|
||||
|
||||
%p
|
||||
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:
|
||||
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:
|
||||
|
||||
%p <code>## 0.0.5 - 2014-12-13 [YANKED]</code>
|
||||
|
||||
%p
|
||||
L'etichetta <code>[YANKED]</code> è in maiuscolo per un motivo.
|
||||
È importante che le persone la notino.
|
||||
Poiché è racchiusa tra parentesi quadre è anche
|
||||
più semplice da riconoscere nel parsing automatizzato.
|
||||
Poiché è racchiusa tra parentesi quadre è anche
|
||||
più semplice da riconoscere nel parsing automatizzato.
|
||||
|
||||
|
||||
%h4#rewrite
|
||||
@ -266,13 +275,13 @@ version: 1.0.0
|
||||
|
||||
%p
|
||||
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.
|
||||
delle pull request per aggiungere release mancanti ai progetti open source che non mantengono
|
||||
correttamente i changelog.
|
||||
|
||||
%p
|
||||
È 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.
|
||||
È 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.
|
||||
|
||||
%h4#contribute
|
||||
%a.anchor{ href: "#contribute", aria_hidden: "true" }
|
||||
@ -280,11 +289,11 @@ version: 1.0.0
|
||||
|
||||
%p
|
||||
Questo documento non è la <strong>verità assoluta</strong>; è solo la mia attenta
|
||||
opinione, arricchita dalle informazioni ed esempi che ho raccolto.
|
||||
opinione, arricchita dalle informazioni ed esempi che ho raccolto.
|
||||
|
||||
%p
|
||||
Questo è perché voglio che la nostra comunità raggiunga un consenso. Credo che
|
||||
la discussione sia importante almeno quanto il risultato finale.
|
||||
la discussione sia importante almeno quanto il risultato finale.
|
||||
|
||||
%p
|
||||
Quindi per favore <strong>#{link_to "partecipate e dateci dentro", gh}</strong>.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user