Quanto dovrebbero essere dettagliate le note di rilascio pubbliche? [chiuso]

-1

Quando si rilascia un aggiornamento software, quanto dovrebbero essere dettagliate le note? In particolare, quanto dovrebbero essere dettagliate le correzioni dei bug?

    
posta Omar 30.06.2011 - 23:45
fonte

5 risposte

4

Dovrebbe contenere tutto ciò che vuoi che i tuoi utenti sappiano è cambiato.

    
risposta data 30.06.2011 - 23:48
fonte
3

La cosa più semplice da fare per correggere i bug è solo elencare il sommario (e forse alcuni dei dettagli) e dichiarare che è stato corretto. Se questi sono online puoi collegare a informazioni più dettagliate per coloro che sono interessati.

La persona che lo ha segnalato saprà qual è il problema senza ulteriori spiegazioni. Tutti gli altri possono seguire il link.

Di solito la maggior parte delle segnalazioni di bug sono abbastanza criptici per chiunque non abbia riscontrato il problema, e gli sviluppatori segnalati spesso descrivono il problema piuttosto che i sintomi che l'utente vedrà.

    
risposta data 30.06.2011 - 23:50
fonte
2

Per favore, per favore, documenta tutto ciò che hai cambiato.

Provare a utilizzare il (vecchio) Mil-Std 498 Software Versione Descrizione Definizione elemento dati (SVD DID) In inglese è un modello di note di rilascio

Per ogni modifica considera la documentazione

  • ID problema: ad es. FOO-354 (le esportazioni excel più vecchie non vengono reimportate correttamente) natura del problema: difetto [o miglioramento o nuova funzione]

  • cosa è stato modificato: la funzione di importazione excel è stata aggiornata per identificare le colonne di importazione dalle intestazioni delle colonne

  • perché è stato modificato: il formato si è evoluto nel tempo e continuerà ad evolversi, i formati precedenti hanno alcune colonne mancanti.

  • cosa significa per gli utenti: in futuro, le esportazioni di Excel in futuro verranno sempre importate, indipendentemente dalla loro età.

So che è più di quanto la maggior parte delle persone di solito faccia, ma è un approccio davvero professionale che rende più facile agli utenti capire cosa sta succedendo.

Il tuo sistema di tracciamento dei difetti potrebbe avere la maggior parte di questi dati. Il tuo team potrebbe anche evolversi per avere una documentazione sui difetti così professionale che i tuoi utenti possono ottenerla per lo più inedita.

Una storia per illustrare il motivo per cui questo livello di dettaglio è buono.

Una volta, Sun Microsystems ha rilasciato un aggiornamento del sistema operativo a Solaris. Versione 2.5 IIRC. Il nostro sistema di controllo di fabbrica funzionava abbastanza bene su 2.4. Quando abbiamo messo 2.5 in servizio su un sistema per il test, un interprete scritto in C ha smesso di funzionare. Mi ci sono voluti mesi per capire che la vecchia implementazione di strcmp () era stata l'esempio di Brian Kernighan e The C Programming Language di Dennis Ritchie. L'esempio ha un percorso di corrispondenza della sottostringa se una stringa è più corta dell'altra. Lo standard C dice che le stringhe sono diverse se hanno lunghezze diverse. Così Sun aggiornò la libreria per seguire lo sntard, e le note di rilascio dicevano qualcosa di non utile come "conformità allo standard ISO C". Mi ci sono voluti mesi per trovare la fonte del problema. TLDR; Sun non ha fatto ciò che sto suggerendo, ha perso 3 mesi della mia vita.

    
risposta data 01.07.2011 - 02:14
fonte
1

Potrebbe anche dipendere dal pubblico di destinazione del software in questione. Se si tratta di uno strumento per gli sviluppatori, potrebbe piacere vedere più dettagli di quelli rivolti agli utenti generici.

    
risposta data 01.07.2011 - 00:04
fonte
0

L'unica cosa che posso dire è non considerare un log di repository di origine "Note di rilascio". L'ho visto su diversi progetti e li ho trovati completamente inutili.

    
risposta data 01.07.2011 - 04:40
fonte

Leggi altre domande sui tag