diff --git a/source/it-IT/1.0.0/index.html.haml b/source/it-IT/1.0.0/index.html.haml index 2922635..6c6ebd0 100644 --- a/source/it-IT/1.0.0/index.html.haml +++ b/source/it-IT/1.0.0/index.html.haml @@ -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" @@ -34,7 +33,7 @@ version: 1.0.0 Cos'è un changelog? %p - Un changelog è un file che contiene una lista curata e ordinata cronologicamente + Un changelog è un file che contiene una lista curata e ordinata cronologicamente delle modifiche degne di nota per ogni versione di un progetto. %h3#why @@ -42,7 +41,7 @@ version: 1.0.0 Perché tenere un changelog? %p - Per rendere facile agli utilizzatori e contribuenti vedere con precisione quali modifiche + Per rendere facile agli utilizzatori e contribuenti vedere con precisione quali modifiche importanti sono state fatte tra ogni release (o versione) del progetto. %h3#who @@ -50,7 +49,7 @@ version: 1.0.0 Chi ha bisogno di un changelog? %p - Le persone ne hanno bisogno. Che si tratti di consumatori o di sviluppatori, gli utenti finali + Le persone ne hanno bisogno. Che si tratti di consumatori o di sviluppatori, gli utenti finali del software sono persone interessate a ciò che avviene in esso. Se il software è cambiato, allora le persone vogliono sapere come e perché. @@ -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 @@ -101,7 +100,7 @@ version: 1.0.0 %li %code Security per invitare gli utilizzatori ad aggiornare in caso di vulnerabilità. - + .effort %h3#effort @@ -109,8 +108,8 @@ version: 1.0.0 Come posso ridurre gli sforzi necessari a mantenere un changelog? %p - Tieni una sezione Unreleased in cima al changelog in modo da tenere traccia - dei cambiamenti imminenti. + Tieni una sezione Unreleased 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 @@ -136,11 +137,11 @@ version: 1.0.0 modifiche della documentazione, etc. %p - Lo scopo di un commit è quello di documentare un passo nell'evoluzione + Lo scopo di un commit è quello di documentare un passo nell'evoluzione del codice sorgente. Alcuini progetti ripuliscono i commit, altri non lo fanno. %p - Lo scopo di una voce changelog è quello di documentare le differenze rilevanti, + Lo scopo di una voce changelog è quello di documentare le differenze rilevanti, spesso attraverso commit mulptipli, per comunicarli in mdo chiaro agli utenti finali. %h4#ignoring-deprecations @@ -149,11 +150,11 @@ version: 1.0.0 %p Quando le persone aggiornano da una versione ad un'altra, dovrebbe essere dolorosamente chiaro quando qualcosa si romperà. - Dovrebbe essere possibile eseguire l'aggiornamento a una versione - che elenca le deprecazioni, rimuove ciò che è deprecato, quindi + Dovrebbe essere possibile eseguire l'aggiornamento a una versione + che elenca le deprecazioni, rimuove ciò che è deprecato, quindi aggiorna alla versione in cui le deprecazioni diventano rimozioni. %p - Se non fai nient'altro elenca le deprecazioni, le rimozioni e + Se non fai nient'altro elenca le deprecazioni, le rimozioni e qualsiasi altro cambiamento nel tuo changelog. %h4#confusing-dates %a.anchor{ href: "#confusing-dates", aria_hidden: "true" } @@ -161,14 +162,14 @@ version: 1.0.0 %p Negli Stati Uniti si mette prima il mese nelle date (06-02-2012 sta per - il 2 Giugno 2012), mentre molte persone nel resto del mondo scrivono un + il 2 Giugno 2012), 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 #{link_to "ISO standard", iso}. + 2012-06-02 funziona con la logica dal più grande al più piccolo, + non ha sovrapposizioni ambigue con altri formati di date, ed è uno #{link_to "ISO standard", iso}. Per tutti questi motivi, è il formato di date raccomandato per i changelog. %aside - C'è di più. Aiutatemi a collezionare questi anti-modelli + C'è di più. Aiutatemi a collezionare questi anti-modelli = link_to "aprendo un issue", issues o una pull request. @@ -181,14 +182,14 @@ version: 1.0.0 Esiste un formato standard per i changelog? %p - Non esattamente. Esistono le linee guida GNU sullo stile dei changelog, oppure + 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. %p Questo progetto vuole essere = link_to "una migliore convenzione per i file changelog.", changelog - Per questo motivo osserviamo le migliori pratiche della comunità open source + Per questo motivo osserviamo le migliori pratiche della comunità open source e le portiamo avanti. %p @@ -205,41 +206,48 @@ version: 1.0.0 HISTORY, NEWS o RELEASES. %p - Mentre è facile pensare che il nome del tuo file changelog - non sia poi così importante, perchè non rendere facile la + Mentre è facile pensare che il nome del tuo file changelog + non sia poi così importante, perchè non rendere facile la vita ai tuoi utenti, usando sempre lo stesso nome? %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 v1.0.0) - 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 + v1.0.0) 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 - apparire molto simile al formato di Keep a Changelog, tuttavia tende + 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 - (README, CONTRIBUTING, 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 (README, + CONTRIBUTING, 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 ## 0.0.5 - 2014-12-13 [YANKED] %p - 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 automatizzato. + 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 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 verità assoluta; è 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 #{link_to "partecipate e dateci dentro", gh}.