Esempi di note di rilascio: 5 note compilate da copiare

Questi esempi di note di rilascio coprono cinque situazioni frequenti, dall'annuncio di una nuova funzionalità in un'app SaaS a un hotfix, da un aggiornamento per gli store di app a una modifica datata di un'API, fino al passaggio di tutta l'azienda a un nuovo strumento IT. I team di prodotto, di sviluppo e IT possono copiare il testo di ciascun esempio, e ognuno ha il suo PDF.

Vai subito agli esempi.

Cosa rende efficace un esempio di note di rilascio

Ogni esempio della raccolta richiama questi sette criteri per numero.

1. Riga di intestazione con versione e data. Apri con il nome del prodotto, il numero di versione o di build, la data di rilascio e, se cambia da una piattaforma all'altra, dove è stato rilasciato (web, iOS, API). Chi salta questa riga non capisce se la nota riguarda la versione che usa.
2. Breve riepilogo in apertura. Da una a tre frasi prima di qualsiasi elenco spiegano chi è coinvolto e in che modo. Senza di esse, il lettore finisce subito negli elenchi puntati.
3. Formulazione orientata al risultato. Ogni voce descrive qualcosa che il lettore ottiene o un problema che non ha più ("Ora puoi..."). Una formulazione debole elenca componenti interni ("Pipeline di indicizzazione della ricerca ottimizzata").
4. Etichette per tipo di modifica. Le voci stanno sotto un'etichetta di tipo, come Corretto o Incompatibile, e quelle simili sono raggruppate. Senza etichette, una correzione e una nuova funzionalità si confondono.
5. Correzioni di bug precise, con il prima e il dopo. Ogni correzione abbina il sintomo che qualcuno ha incontrato al comportamento attuale del prodotto, una correzione per riga. La versione debole si accontenta di una sola riga generica.
6. Azioni richieste e modifiche incompatibili in primo piano. Tutto ciò che il lettore deve fare va in alto, insieme alla scadenza. Se non serve nulla, la nota scrive "Nessuna azione richiesta". Le note deboli nascondono una modifica incompatibile a metà elenco.
7. Problemi noti e un punto a cui chiedere aiuto. Ciò che non funziona ancora arriva con una soluzione temporanea o con la data della correzione, e la riga finale rimanda alla documentazione o a un contatto di supporto. Ometterla fa pensare che non ci sia nulla di rotto.

5 esempi di note di rilascio da copiare

Ecco cinque esempi, uno per tipo di rilascio, che consideriamo tra i migliori esempi di note di rilascio da cui prendere spunto. Tutte le aziende citate sono di fantasia.

Esempio 1: lancio di una funzionalità SaaS

Per un PM che annuncia una funzionalità in un'app B2B di fatturazione.

• Intestazione: Ledgerly 3.8 · 6 maggio 2026 · Web · Piani Growth e Scale
• Nuovo: le fatture ora si sollecitano da sole
• Riepilogo: Ledgerly ora può inviare promemoria di pagamento secondo un calendario che decidi tu, così i team finance smettono di scrivere a mano le email di sollecito. Disponibile nei piani Growth e Scale.
• Cosa puoi fare ora: impostare fino a 3 promemoria per fattura (per esempio 3 giorni prima della scadenza, il giorno della scadenza e 7 giorni dopo). I promemoria si interrompono da soli quando il pagamento viene registrato. Ogni promemoria usa il branding delle tue fatture.
• Come usarla: (1) Apri Impostazioni > Promemoria. (2) Attiva Promemoria automatici. (3) Scegli un calendario o creane uno tuo. (4) Fai clic su Salva. Il calendario vale per ogni fattura non pagata.
• Ce l'avete chiesto, l'abbiamo fatto: richiesta di funzionalità n. 412 sulla bacheca dei suggerimenti di Ledgerly (230 voti).
• Disponibilità: in distribuzione a tutti gli account Growth e Scale entro il 20 maggio 2026.
• Limite noto: i promemoria vengono inviati solo in inglese. Altre lingue sono previste per il terzo trimestre 2026.
• Assistenza: help.ledgerly.example/reminders

Perché funziona: criteri 1, 2, 3, 4 e 7. Il titolo è il risultato stesso.

Attenzione a: il limite della sola lingua inglese è di Ledgerly. Indica i limiti della tua funzionalità.

Scarica il PDF - Le fatture ora si sollecitano da sole

Esempio 2: aggiornamento di un'app negli store

Un PM mobile che scrive il testo dell'aggiornamento per entrambi gli store.

• Intestazione: Trailmate · Novità della versione 5.12 · 2 giugno 2026 · iOS e Android
• Le mappe offline ora si scaricano in background, così puoi bloccare il telefono e continuare a camminare.
• Nuovo: una linea del ritmo sul grafico altimetrico mostra dove hai rallentato in ogni salita.
• Corretto: la traccia GPS non si interrompe più quando apri la fotocamera durante l'escursione.
• Corretto: l'app per Apple Watch ora mostra la distanza in miglia quando il telefono è impostato in miglia.
• Riga finale: Grazie per le segnalazioni che ci hanno aiutato a correggere questi problemi. Domande? support.trailmate.example

Contando i simboli degli elenchi e gli a capo, le quattro righe arrivano a 341 dei 500 caratteri di Google Play.

Perché funziona: criteri 1, 2, 3, 4, 5 e 7. Ogni correzione descrive ciò che l'escursionista vedeva.

Attenzione a: un quinto punto potrebbe far superare al testo il limite di 500 caratteri di Google Play.

Scarica il PDF - Novità della versione 5.12

Esempio 3: patch di correzione dei bug

Per un responsabile del supporto che annuncia un hotfix già attivo in un software di pianificazione dei turni.

• Intestazione: Hotfix Rostra 2.14.1 · 18 giugno 2026 · Web, iOS, Android
• Riepilogo: questo hotfix risolve due problemi introdotti nella 2.14.0. La correzione è attiva per tutti gli account. Nessuna azione richiesta.
• Corretto: gli scambi di turno approvati nell'app mobile non comparivano nel calendario web finché non si aggiornava la pagina. Ora gli scambi approvati appaiono sul web entro 5 secondi.
• Corretto: gli avvisi di straordinario scattavano a 38 ore invece che a 40 per gli account con la settimana che inizia di lunedì. Ora gli avvisi scattano a 40 ore, e quelli inviati per errore sono stati rimossi.
• Utenti interessati: account con inizio settimana di lunedì che hanno usato gli avvisi di straordinario tra il 16 e il 18 giugno 2026.
• Causa: l'impostazione di inizio settimana veniva letta in UTC invece che nel fuso orario dell'account.
• Problema noto: le esportazioni CSV degli scambi di turno mostrano ancora gli orari in UTC. La correzione arriva con la 2.14.2 il 25 giugno 2026.
• Assistenza: support@rostra.example

Perché funziona: criteri 1, 2, 5, 6 e 7, con "Nessuna azione richiesta" in apertura.

Attenzione a: la riga sulla causa. Limita la tua a una sola riga.

Scarica il PDF - Hotfix Rostra 2.14.1

Esempio 4: modifica di versione di un'API

Un team di piattaforma comunica agli integratori una versione datata dell'API.

• Intestazione: API Parcelo versione 2026-07-01 · Rilasciata il 1° luglio 2026 · Azione richiesta entro il 15 gennaio 2027
• Riepilogo: la versione 2026-07-01 cambia il modo in cui le tariffe restituiscono i prezzi e rinomina un campo. La tua integrazione continua a funzionare sulla versione fissata finché non esegui l'aggiornamento. L'endpoint v1 delle etichette smette di funzionare il 15 gennaio 2027.
• Incompatibile: GET /rates restituisce amount come intero in centesimi (1299) invece che come stringa decimale ("12.99").
• Incompatibile: il campo carrier è rinominato in carrier_code.
• Nuovo (compatibile): estimated_delivery (data ISO 8601) su ogni tariffa.
• Deprecato: POST /v1/labels, dismesso il 15 gennaio 2027. Usa invece POST /v2/labels.
• Come aggiornare: (1) Invia l'header Parcelo-Version: 2026-07-01 in un ambiente di test. (2) Dividi amount per 100 ovunque mostri i prezzi. (3) Sostituisci carrier con carrier_code. (4) Sposta le chiamate per le etichette su /v2/labels.
• Prima: {"carrier": "UPS", "amount": "12.99"}
• Dopo: {"carriercode": "ups", "amount": 1299, "estimateddelivery": "2026-07-04"}
• Assistenza: docs.parcelo.example/changelog/2026-07-01 e il canale #api nella community degli sviluppatori di Parcelo.

Perché funziona: criteri 1, 2, 3, 4, 6 e 7. La scadenza e la data di dismissione stanno in cima.

Attenzione a: il cambio di tipo di amount, che è incompatibile. Accompagna ogni cambio di tipo con un esempio di codice prima e dopo.

Scarica il PDF - API Parcelo versione 2026-07-01

Esempio 5: introduzione di uno strumento IT interno

Per il team IT Operations che presenta uno strumento a circa 420 dipendenti di Northwind Freight, un'azienda di logistica.

• Intestazione: Rilascio IT: gestore di password Vaultkey · Distribuzione dal 7 al 21 luglio 2026 · Tutto il personale
• Riepilogo: Vaultkey sostituisce il foglio di calcolo condiviso 'Team Passwords'. Tutti passano al nuovo strumento in tre fasi, e il foglio di calcolo diventa di sola lettura il 28 luglio.
• Fasi di distribuzione: Finance e HR il 7 luglio, Operations e Dispatch il 14 luglio, tutti gli altri il 21 luglio.
• Cosa cambia per te: l'estensione Vaultkey per il browser si installa da sola sui portatili aziendali. I vault del team sostituiscono le schede del foglio di calcolo. Il foglio diventa di sola lettura il 28 luglio 2026 e il team IT lo archivia il 31 agosto 2026.
• Cosa devi fare (azione richiesta entro 2 giorni dalla tua fase): (1) Accetta l'email di invito di Vaultkey. (2) Imposta una master password di almeno 14 caratteri. (3) Facoltativo: installa l'app mobile di Vaultkey.
• Problema noto: su Safari, attiva tu l'estensione da Impostazioni > Estensioni.
• Rollback: il team IT conserva il backup del foglio di calcolo fino al 31 agosto 2026.
• Assistenza: il canale Slack #it-help e gli orari di ricevimento IT il martedì e il giovedì alle 14:00.
• Responsabile: Priya Raman, IT Operations.

Perché funziona: criteri 1, 2, 3, 6 e 7. Ogni azione ha una scadenza.

Attenzione a: le date fissate per ogni fase. Se una slitta, invia di nuovo la nota.

Scarica il PDF - Rilascio IT: gestore di password Vaultkey

Come adattare un esempio di note di rilascio

1. Scegli l'esempio della raccolta più vicino al tuo tipo di rilascio. Scegli in base al tipo di rilascio: lancio di una funzionalità, aggiornamento negli store, hotfix, modifica di un'API o introduzione interna. Se nessuno è adatto, il punto di partenza è il modello di note di rilascio da compilare.
2. Adatta il livello di dettaglio all'entità della modifica. I grandi lanci meritano un contesto e un'immagine. Le piccole modifiche possono confluire in un breve riepilogo, e una patch dovrebbe aprire con ciò che corregge.
3. Mantieni l'etichetta del tipo e il breve riepilogo. Conserva questi due campi a qualsiasi dimensione, anche quando tagli tutto il resto.
4. Riscrivi ogni voce partendo dal risultato. Sostituisci i termini tecnici con l'effetto che l'utente nota.
5. Rispondi a "mi riguarda?" nella prima frase. Indica chi ne trae vantaggio o chi deve intervenire.
6. Verifica i fatti con il team che l'ha sviluppato. Chiedi agli sviluppatori che hanno rilasciato la modifica di confermare comportamento, piani, piattaforme e versione prima della pubblicazione.
7. Etichetta la voce perché i lettori la ritrovino in seguito. Assegnale una data, un tipo di modifica, un'etichetta dell'area di prodotto e un URL permanente, e usa lo stesso schema a ogni rilascio.

Quando servono le note di rilascio

Servono soprattutto per i rilasci grandi che coinvolgono più prodotti o tenant aziendali, perché gli amministratori devono filtrare per prodotto, piattaforma e versione per capire cosa li riguarda. Servono anche per i rilasci più piccoli: una nuova funzionalità in un'app web (Esempio 1), o un hotfix i cui utenti vogliono sapere se il loro problema è risolto (Esempio 3).

Sul mobile e nelle API valgono limiti rigidi. Apple limita il testo dell'aggiornamento a 4.000 caratteri sull'App Store, e Google ne consente 500 su Google Play (Esempio 2). Gli integratori di un'API devono essere avvisati nel momento in cui una scadenza li obbliga a modificare il codice (Esempio 4).

Anche gli strumenti interni contano. La nota dice al personale di supporto, ai commerciali e ai responsabili dei sistemi cosa è cambiato, a chi rivolgersi e come funziona un rollback (Esempio 5).

Errori comuni nelle note di rilascio

• Scrivere in gergo tecnico o copiare i ticket parola per parola. Una riga come "Pipeline di indicizzazione della ricerca ottimizzata", o un messaggio di commit così com'è, non dice nulla sul lavoro del lettore. Le persone smettono di leggere.
• Voci vaghe come "correzioni di bug e miglioramenti delle prestazioni". Chi ha segnalato un bug non capisce se è stato corretto, e il supporto riceve un altro ticket.
• Nascondere modifiche incompatibili e passaggi obbligatori a metà elenco. Se è solo un punto tra tanti, una modifica incompatibile passa inosservata, e le integrazioni si rompono quando arriva la scadenza.
• Pubblicare un lungo registro senza interruzioni e senza riepilogo. Senza un riepilogo, i lettori devono scorrere ogni punto per capire se qualcosa li riguarda.
• Lasciare che lo stile copra ciò che è cambiato. Chi cerca una modifica non la trova sotto un titolo brillante che non nomina nessuna funzionalità.

Niente pagina bianca: registra il rilascio

I team che fanno una demo di ogni rilascio possono registrare la sessione e consegnarla a Hinto AI, il cui modello "Novità" produce una prima bozza della nota. Hinto accetta link di Loom, Zoom e YouTube, file caricati in MP4, MOV e WebM e registrazioni dello schermo fatte con il suo registratore nell'app web o nella Chrome Extension.

Durante l'elaborazione del video, Hinto individua i clic sui pulsanti e i cambi di schermata ed estrae screenshot e passaggi scritti. Per il team di sviluppo, la registrazione della demo di uno sprint può diventare un elenco consultabile di correzioni di bug.

Una sezione che non convince si può selezionare e rigenerare, immagini comprese. La nota finita può stare su una pagina pubblica sotto il tuo dominio, essere prodotta in oltre 50 lingue o essere inviata a Intercom, Notion, Confluence, GitHub o GitLab.

Domande frequenti sulle note di rilascio

Quali etichette usare nelle note di rilascio?

Limitati a sei: Nuovo, Migliorato, Corretto, Deprecato, Incompatibile e Problema noto. Raggruppare le voci per etichetta permette a ogni lettore di andare dritto alla parte che lo riguarda. Senza etichette, le correzioni si mescolano alle funzionalità, ed è facile perdere la modifica che serve a un determinato utente.

Le note di rilascio devono includere screenshot o video?

Per le modifiche visibili, sì. Una schermata ridisegnata si capisce prima da un'immagine annotata, una GIF o un breve video che da un testo, e rimandare alla documentazione evita di scrivere un manuale dentro la nota. Per le correzioni minori basta il testo.

Come si scrivono le note di rilascio per una modifica di un'API?

Apri con le modifiche al codice che gli integratori devono fare e la relativa scadenza, sotto un'intestazione a parte. Sotto, elenca le modifiche incompatibili, i nuovi campi e gli endpoint deprecati, uno per riga, poi numera i passaggi di aggiornamento. Nell'Esempio 4, l'intestazione di Parcelo dice "Azione richiesta entro il 15 gennaio 2027" prima di ogni altra cosa.

Come si scrivono note di rilascio che la gente legge davvero?

Apri ogni voce con il vantaggio, per esempio "Le esportazioni di grandi dimensioni non vanno più in timeout." Lascia fuori i nomi dei componenti interni. L'Esempio 1 apre con "Le fatture ora si sollecitano da sole" e un riepilogo del risultato, poi i passaggi di configurazione.

Esempi correlati

Esempi di manuale utente, Esempi di knowledge base, Esempi di documentazione dei processi