Come dovrebbe release notes essere scritto?

C’è qualche sorta di linee guida o buone pratiche su come note di rilascio, dovrebbe essere scritto? Credo che sto cercando di trovare il giusto equilibrio tra il fare il punto, senza essere troppo specifici. Inoltre, sviluppatore di solito a fornire una più note di rilascio per QA squadra rispetto a quella presentata per la vista pubblica?

  • Buona domanda, ma senza alcuni particolari non si ottiene una risposta utile. Grosso modo quello che si sta liberando, come e chi troppo sarà di aiuto.
  • possibile duplicato di note di Rilascio per che cosa?
InformationsquelleAutor DeFiNite | 2009-03-12



6 Replies
  1. 28

    Pubblico note di rilascio deve contenere almeno:

    • rilascio, buildnumber
    • tutti corretti bug pubblici
    • tutte le pubbliche aggiunti caratteristiche

    QA note di rilascio deve contenere almeno:

    • rilascio, buildnumber
    • tutti i bug tra cui il numero di bug
    • tutte le funzionalità aggiunte, compresi i collegamenti per la progettazione di documenti

    Prendere in considerazione il vostro pubblico e provate a pensare che cosa hanno bisogno.

    Un’altra cosa da aggiungere è nuovo o interrotto il supporto per alcune piattaforme. (Per esempio abbiamo smesso di supporto per Win3.1 e aggiunto il Vista a 64 bit).

    • Alcuni ulteriori punti: – Pubblicare in formato testo o html. Non li rendono difficili da visualizzare. – È comune per aggiungere note di rilascio sulla parte superiore di vecchie note di rilascio. – È a volte bene, a fare riferimento a significative noto bug non ancora risolti.
    • Bella aggiunta. Mi sarebbe sicuramente andare per il testo normale. Ma se si è in grado di generare le note di rilascio, non c’è alcun motivo per non inlcude html, pdf, ecc..
  2. 11

    Se si dispone di un progetto di gestione/sistema di monitoraggio dei problemi, si dovrebbe essere utilizzando per generare le note di rilascio. Trac e Redmine, in particolare, sono molto bravi in questo.

    Punti di emissione devono avere alcune proprietà, IMO:

    • Ricordate che il vostro pubblico. Se questa è una app per iPhone, alcuni stanno andando a preoccuparsi del fatto che un particolare errore di logica on line 572 in classe Pippo è stato risolto. Ma non ti interessa molto “app è ora accelerometro-sensibili”.
    • Riassumere le novità, le caratteristiche e correzioni di bug in un’ampia, spazzare via, se possibile. Se si è in grado di legare questi insieme tematico (ad esempio, “abbiamo implementato i farmaci generici e i tipi anonimi”), un breve trafiletto su che è un buon modo per dare alla gente l’immagine grande.
    • Itemize le cose specifiche che sono stati risolti, con il link al tuo pubblico bug-tracker, se qualsiasi. Questo di solito può essere generato automaticamente.
    • Non forniscono maniacale precisione. Uno o due liner sintesi di ogni cosa che è stato aggiunto o fisso dovrebbe essere sufficiente.
    • Sempre includere specifiche di rilascio di identificazione (ad es. “v. 1.4.5”), come appropriato.
  3. 2

    Dipende molto dal pubblico.
    Per gli utenti tecnici (per esempio gli sviluppatori che utilizzano le API), si può essere molto tecnico.
    All’altra estremità di alto livello agli utenti finali di un’applicazione creata potrebbe essere solo interessato a nuove funzionalità e di grandi cambiamenti.

    In mezzo ci sono gli utenti non tecnici che hanno bisogno di dettagli, per esempio il reparto di assistenza. Per quelle persone in grado di dare una descrizione dettagliata senza il basso livello di specifiche tecniche, per esempio “Risolto un bug per cui il record non è stato salvato nel database.”.

  4. 0

    Principale collaboratore di Note di Rilascio sarebbe proprio team di sviluppo. È una buona pratica per consentire a sviluppatori e tester per catturare eventuali note di rilascio relative informazioni contro i vostri elementi di lavoro che è collegato a insiemi di modifiche in TFS.

    Quindi è possibile utilizzare un progetto open source come http://tfschangelog.codeplex.com per generare le note di rilascio. È la versione GUI e una versione a riga di comando che rende facile pianificare le note di rilascio di report su base giornaliera.

Lascia un commento