Czy istnieją jakieś wskazówki lub najlepsze praktyki dotyczące sposobu sporządzania not dotyczących wydania? Sądzę, że staram się znaleźć odpowiednią równowagę między robieniem punktu bez bycia zbyt szczegółowym. Czy deweloper zwykle dostarcza znacznie więcej informacji o wydaniu zespołowi kontroli jakości w porównaniu z zgłoszonym do publicznego oglądania?W jaki sposób powinny być zapisywane notatki do wydania?
publiczne wydaniu powinna zawierać co najmniej:
release notes QA powinien zawierać co najmniej:
Zastanów się publiczności i spróbuj pomyśleć, czego potrzebują.
Inną rzeczą, którą należy dodać, jest nowa lub wycofana obsługa niektórych platform. (Na przykład opuściliśmy obsługę Win3.1 i dodano 64-bitową wersję systemu Vista).
Niektóre dodatkowe punkty [Uwagi do wydania, po co?]: - Publikowanie w postaci zwykłego tekstu lub przynajmniej html . Nie utrudniaj ich przeglądania. - Często dodaje się uwagi do wydania do starszych uwag do wydania. - Czasami dobrze jest odnosić się do znanych znanych błędów, które nie zostały jeszcze rozwiązane. –
Niezły dodatek. Zdecydowanie sięgnę po zwykły tekst. Ale jeśli możesz wygenerować notatki do wydania, nie ma powodu, aby nie uwzględniać html, pdf itp. –
Jeśli posiadasz system zarządzania projektami/śledzenia zgłoszeń, zdecydowanie powinieneś używać go do generowania informacji o wydaniu. Trac i Redmine w szczególności są w tym bardzo dobre.
punkty wydanie powinno mieć kilka właściwości, IMO:
To naprawdę zależy od odbiorców. Użytkownicy techniczni (na przykład programiści używający Twojego interfejsu API) mogą być bardzo techniczni. Z drugiej strony zaawansowani użytkownicy końcowi tworzonej aplikacji mogą być zainteresowani wyłącznie nowymi funkcjami i poważnymi zmianami.
W między są nietechnicznym użytkownikom, którzy potrzebują zbyt szczegółowe, na przykład działu wsparcia. Dla tych osób możesz podać szczegółowy opis bez szczegółów technicznych niskiego poziomu, na przykład "Naprawiono błąd, który nie został zapisany w bazie danych.".
Jeden z najlepszych praktyk release notes moim zdaniem jest automatyzacja. Jeśli istnieją pewne sprawdzone metody przesyłania komunikatów systemu kontroli wersji (http://drupal.org/node/52287), można utworzyć uwagi do wydania za pomocą automatycznego skryptu (http://cvs.drupal.org/viewvc.py/drupal/contributions/tricks/cvs-release-notes/). Pozwoliłoby to na stworzenie naprawdę ładne informacje o wydaniu: http://drupal.org/node/226165
Główny specjalista od Release Notes będzie zespół rozwoju. Dobrą praktyką jest umożliwienie programistom i testerom przechwycenia wszelkich informacji związanych z uwagami do wydania w odniesieniu do twoich elementów pracy, które są powiązane z zestawami zmian w TFS.
Następnie można użyć Projekt open source jak http://tfschangelog.codeplex.com generować informacje o wersji. Posiada wersję GUI i wersję wiersza poleceń, co ułatwia planowanie raportów o wydaniach każdego dnia.
Dobre pytanie, ale bez pewnych szczegółów nie dostaniesz użytecznej odpowiedzi. Z grubsza to, co wypuszczasz, jak i kto też pomoże. –
możliwe duplikat (http://stackoverflow.com/questions/315628/release-notes-what-for) – lindelof