Il modello per le note di rilascio

Questo modello per le note di rilascio definisce le 11 sezioni di cui un team di shipping ha bisogno per comunicare agli utenti cosa è cambiato. Copia l'intera struttura senza registrazione, oppure scaricalo in PDF.

Il modello per le note di rilascio (pronto da copiare e incollare)

Il blocco qui sotto è il modello completo, libero da copiare all'istante, senza registrazione né passaggio via email. Si incolla senza modifiche in Word, Google Docs, Confluence, Notion o un file Markdown, e il PDF contiene le stesse 11 sezioni se preferisci stamparlo. Sostituisci i suggerimenti tra parentesi, poi elimina le sezioni che questo rilascio non tocca.

[Nome del prodotto] Note di rilascio
Versione: [x.y.z]
Data di rilascio: [YYYY-MM-DD]
Piattaforma / ambiente: [web, iOS, Android, API, staging]

Riepilogo delle modifiche (Scopo)
[Una o due frasi: cosa affronta questo rilascio e chi coinvolge]

Nuove funzionalità
- [Cosa può fare ora l'utente, non il nome interno della funzionalità]

Miglioramenti e ottimizzazioni (Performance Improvements)
- [Cosa esisteva già, e cosa è migliorato dal punto di vista dell'utente]

Correzioni di bug
- Corretto: [cosa vedeva prima l'utente, e cosa succede ora]

Modifiche non retrocompatibili e passaggi di migrazione
- [Cosa smette di funzionare], quindi [cosa devi cambiare, ed entro quando]

Problemi noti e soluzioni temporanee (Ongoing Issues)
- [Problema irrisolto] · [piattaforma interessata] · [soluzione temporanea] · [tempistica della correzione]

Passaggi di aggiornamento o installazione (Upgrade Steps / Installation Notes)
1. [Cosa deve fare il lettore per passare alla nuova versione]

Deprecazioni
- [Funzionalità, integrazione o API] è deprecata dal [data]. [A cosa passare]

Note sulla sicurezza
- [Modifica rilevante per la sicurezza, descritta senza dettagliare la vulnerabilità]

Dove ottenere aiuto e lasciare un feedback
- Documentazione: [link] · Supporto: [email o canale] · Feedback: [link]

Cosa contiene un modello per le note di rilascio

Un modello per le note di rilascio ha undici sezioni, ciascuna con un compito preciso. Scrivi ogni sezione per chi la legge: sviluppatori e clienti hanno bisogno di cose diverse.

Come usare il modello per le note di rilascio

1. Copia il modello nel posto in cui vive già il tuo rilascio. Si incolla senza modifiche in Jira, Confluence, Notion, GitHub o Azure DevOps, così la nota resta accanto al lavoro invece che in un documento a parte.
2. Compila prima la riga di intestazione. Nome del prodotto, numero di versione, data di rilascio e piattaforma, così chiunque arrivi sulla nota sa quale build descrive prima ancora di leggere una parola.
3. Raccogli il registro delle modifiche e ordinalo per ciò che vede l'utente. Suddividi ogni modifica in nuove funzionalità, miglioramenti, correzioni di bug e qualsiasi cosa si rompa, e scarta le voci che restano invisibili agli utenti.
4. Scrivi ogni voce come capacità, non come implementazione. "Implementata l'elaborazione batch" diventa "Ora puoi esportare grandi set di dati senza che il processo vada in timeout", il che risponde alla domanda del lettore su se questo rilascio lo riguardi.
5. Aggiungi uno screenshot o una breve GIF ovunque l'interfaccia sia cambiata. Se una voce richiede tre paragrafi, probabilmente le serve invece una GIF di quindici secondi.
6. Elimina le sezioni che questo rilascio non tocca e lascia le altre in ordine. Una patch elimina le nuove funzionalità e i passaggi di aggiornamento, e gli utenti non dovrebbero dover reimparare la struttura a ogni rilascio.
7. Passa la bozza a un unico responsabile designato, poi pubblica. Senza una persona sola responsabile dell'approvazione, la nota esce in ritardo o esce due volte.

Modello per le note di rilascio: un esempio compilato

Questo è lo stesso modello, compilato per un prodotto di dispatch immaginario che rilascia una nuova funzionalità.

• Fieldpost 4.2.0 · Rilasciato: 12 marzo 2026 · Piattaforma: Web e iOS
• Riepilogo delle modifiche: Ora le esportazioni si completano sugli account di grandi dimensioni, i prezzi per il Canada sono corretti, e gli amministratori self-hosted hanno un unico passaggio di migrazione.
• Nuove funzionalità
• Esportazioni programmate. Ora puoi impostare un report da eseguire ogni lunedì e recapitarlo nella tua casella di posta.
• Aggiornamenti di stato in blocco. Seleziona fino a 500 job e cambiane lo stato in un'unica azione.
• Miglioramenti e ottimizzazioni
• Bacheca dispatch più veloce. La bacheca si carica in circa due secondi su account con 10.000 job aperti, contro i nove precedenti.
• Correzioni di bug
• Corretto: le esportazioni oltre 50.000 righe andavano in timeout e restituivano un file vuoto.
• Corretto: i prezzi venivano mostrati in USD per gli account canadesi.
• Modifiche non retrocompatibili e passaggi di migrazione
• La versione 4.2.0 rimuove l'endpoint v1 /exports. Punta le integrazioni su /v2/exports, che restituisce un job ID. Le installazioni self-hosted eseguono fieldpost migrate --v2-exports prima di avviare la 4.2.0.
• Problemi noti e soluzioni temporanee
• Su iOS, le esportazioni programmate per la domenica vengono eseguite il lunedì. Usa l'app web fino al rilascio della 4.2.1 il 26 marzo.
• Passaggi di aggiornamento o installazione
• Gli account cloud sono già sulla 4.2.0. Gli utenti iOS aggiornano dall'App Store entro il 31 marzo.
• Deprecazioni
• Fieldpost deprecerà il formato report solo CSV il 1° settembre 2026. Passa i report salvati a XLSX.
• Note sulla sicurezza
• I token di sessione ora scadono dopo 12 ore, e gli amministratori possono terminare le sessioni di un altro utente.
• Dove ottenere aiuto e lasciare un feedback
• Documentazione: docs.fieldpost.example · Supporto: support@fieldpost.example · Feedback: la scheda Feedback nell'app.

Varianti del modello per le note di rilascio

Le cinque varianti qui sotto si collocano su due assi: chi legge la nota, e che tipo di rilascio copre. Ognuna mantiene la riga di intestazione e il riepilogo delle modifiche, poi aggiunge, elimina o riscrive le altre nove sezioni. Le differenze sono la parte utile, perché decidere cosa eliminare per un rilascio piccolo è la scelta su cui la maggior parte dei team sbaglia.

Modello per le note di rilascio principali (Major)

Questa variante mantiene tutte le 11 sezioni. Ogni nuova funzionalità ottiene un paragrafo più uno screenshot o una GIF, spieghi i passaggi di migrazione per esteso invece di limitarti a linkarli, e scrivi il riepilogo delle modifiche in modo che stia in piedi da solo, perché è la riga che i colleghi incollano su Slack e ti ricitano.

• Mantiene: tutte le 11 sezioni.
• Espande: nuove funzionalità, modifiche non retrocompatibili e passaggi di migrazione, passaggi di aggiornamento.
• Attenzione: il riepilogo deve avere senso anche senza nessun'altra sezione allegata.

Modello per le note di rilascio di patch o hotfix

Quattro sezioni fanno la maggior parte del lavoro: riga di intestazione, riepilogo, correzioni di bug, e problemi noti se ne restano. Apri con la correzione, poi chi coinvolge, poi se il lettore deve fare qualcosa. Una nota di hotfix che si apre con un numero di versione e seppellisce la correzione nel terzo paragrafo vanifica lo scopo di rilasciarla in fretta.

• Elimina: nuove funzionalità, miglioramenti, deprecazioni, passaggi di aggiornamento.
• Mantiene: riga di intestazione, riepilogo, correzioni di bug, problemi noti.
• Attenzione: dichiara esplicitamente quando non serve alcuna azione.

Modello per le note di rilascio interne o tecniche

Questa la scrivi per il team che gestisce il sistema, quindi via l'inquadramento sui benefici, dentro la meccanica. Nomina i servizi coinvolti, la configurazione che è cambiata, e qualsiasi cosa un collega potrebbe incontrare alle 2 di notte.

• Aggiunge: modifiche al codice, modifiche ad API e database, note su ambiente e configurazione.
• Elimina: l'inquadramento sui benefici per l'utente.
• Mantiene: modifiche non retrocompatibili, problemi noti, passaggi di aggiornamento, che in questa variante pesano più che nelle altre.

Modello per le note di rilascio degli app store mobili

Le schede degli store limitano il numero di caratteri, quindi l'intera nota si comprime in una riga di versione e un breve elenco "novità". Scrivi da tre a cinque punti, ciascuno che nomina una cosa che l'utente può fare ora, ordinati per ciò che gli interessa di più.

• Mantiene: riga di intestazione, un elenco compresso di nuove funzionalità, una riga per le correzioni degne di nota.
• Elimina: problemi noti, deprecazioni, note sulla sicurezza, passaggi di migrazione.
• Attenzione: qualsiasi cosa tolta dalla scheda dello store appartiene comunque alla nota completa che ospiti tu stesso.

Modello per le note di rilascio API

Questa la scrivi per uno sviluppatore che integra con te, non per un utente finale. Ogni voce nomina l'endpoint o il parametro che tocca, e ogni deprecazione porta una data di fine supporto che il lettore può segnare in calendario.

• Aggiunge: modifiche agli endpoint, modifiche ai parametri, un esempio di migrazione con richiesta e risposta.
• Espande: deprecazioni, con date di fine supporto, e modifiche non retrocompatibili.
• Elimina: screenshot e GIF, di cui uno sviluppatore che legge non ha bisogno.

Una patch di sicurezza adotta qualunque variante si adatti al rilascio, con una regola in più: mantieni la nota sulla sicurezza fattuale e non descrivere la vulnerabilità stessa.

Quando usare un modello per le note di rilascio

Ricorri al modello per qualsiasi rilascio che un utente può vedere o su cui deve agire. I tre motivi più comuni sono il lancio di una funzionalità, una correzione di bug o hotfix, e una build interna. Patch di sicurezza, rilasci API e aggiornamenti store adottano la stessa struttura con sezioni diverse in gioco.

Note di rilascio, changelog e patch notes rispondono a domande diverse. Le note di rilascio sono per singolo rilascio e leggibili dall'utente, scritte per il pubblico che la modifica riguarda. Un changelog è il registro cronologico completo, rivolto agli sviluppatori e permanente. Le patch notes sono la nota di rilascio breve per un rilascio dedicato solo a correzioni. Pubblica le note di rilascio quando qualcuno fuori dal team deve agire, e mantieni il changelog che scorre sotto.

La responsabilità funziona come un passaggio di consegne. L'ingegneria fornisce i registri di spedizione, un PM o PMM li traduce in voci rivolte all'utente, e una persona designata approva prima che la nota venga pubblicata.

Salta il documento vuoto: registralo invece

Compilare un modello vuoto è il passaggio che la maggior parte dei team rimanda finché il rilascio non è già uscito. L'altra strada è registrare il walkthrough che avresti comunque fatto e lasciare che diventi la nota.

Hinto AI prende qualsiasi sorgente video, un Loom, una chiamata Zoom, un video YouTube o un MP4 locale, e registra il tuo schermo dall'app web o dall'estensione Chrome. Il suo rilevamento delle azioni con AI identifica i cambi di stato dell'interfaccia e i clic sui pulsanti, estraendo screenshot e passaggi scritti. Quei passaggi diventano le voci di nuova funzionalità, miglioramento e correzione di bug, e il motore GIF copre i campi dove l'interfaccia è cambiata. Hinto offre un modello di progetto "Novità" costruito apposta per le note di rilascio a partire da demo di prodotto.

Da lì modifichi invece di scrivere da zero: seleziona una sezione e chiedi all'AI di riscriverla, poi ospita il risultato su un URL pubblico con dominio personalizzato, oppure sincronizzalo con Notion, Confluence, GitHub o GitLab.

FAQ sul modello per le note di rilascio

Cosa devono contenere le note di rilascio?

Undici sezioni: una riga di intestazione; un riepilogo delle modifiche; nuove funzionalità; miglioramenti; correzioni di bug; modifiche non retrocompatibili e passaggi di migrazione; problemi noti; passaggi di aggiornamento; deprecazioni; note sulla sicurezza; e dove ottenere aiuto. Il riepilogo è la riga che chi scorre il testo legge e che gli agenti citano.

Come si scrivono buone note di rilascio?

Apri con ciò che il lettore può fare ora, e tieni fuori l'implementazione. "Implementata l'elaborazione batch" diventa "Ora puoi esportare grandi set di dati senza che il processo vada in timeout." Metti in grassetto il nome della funzionalità, usa le etichette New, Improved e Fixed, e limita le voci a due o tre frasi.

Chi scrive di solito le note di rilascio?

Un product manager o un product marketing manager, partendo da ciò che l'ingegneria gli consegna. L'ingegneria fornisce i registri di spedizione, il PM o PMM li traduce in voci rivolte all'utente, e un responsabile designato dà l'approvazione finale prima che la nota esca.

Qual è la differenza tra patch notes e note di rilascio?

Le patch notes sono la forma breve per un rilascio dedicato solo a correzioni. Eliminano nuove funzionalità, miglioramenti, deprecazioni e passaggi di aggiornamento, e aprono con la correzione, chi coinvolge, e se il lettore deve agire. Le note di rilascio portano la struttura completa per un rilascio di funzionalità.

Cosa sono le note di rilascio in Jira?

È lo stesso documento, incollato in una superficie specifica. Chi cerca informazioni su Jira, Confluence, GitHub, Notion o Azure DevOps vuole la nota di rilascio in sé, quindi copia il modello qui sopra in qualunque superficie il tuo team già legga. Hinto pubblica su Notion, Confluence, GitHub e GitLab.