Fix multiple identation errors

This commit is contained in:
Olivier Lacan 2017-06-30 02:03:38 +02:00
parent 2a0df6b2a9
commit 92db66e139

View File

@ -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"
@ -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:
@ -125,7 +124,9 @@ version: 1.0.0
%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,33 +213,40 @@ 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
#{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.
@ -247,9 +255,10 @@ 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>