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:
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"
|
||||
@ -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>
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user