Como as notas de liberação devem ser escritas?

Question

Existe algum tipo de diretrizes ou práticas recomendadas sobre como as notas de lançamento devem ser escritas? Acho que estou tentando encontrar o equilíbrio adequado entre fazer o ponto sem ser muito específico. Além disso, o desenvolvedor geralmente fornece uma Notas de lançamento muito mais para a equipe de controle de qualidade em comparação com a enviada para visualização pública?

Answer 1

As notas de lançamento público devem conter pelo menos:

• liberação, BuildNumber
• Todos os bugs públicos corrigidos
• todos os recursos públicos adicionados

As notas de liberação de controle de qualidade devem conter pelo menos:

• liberação, BuildNumber
• Todos os bugs corrigidos, incluindo o número do bug
• Todos os recursos adicionados, incluindo links para os documentos de design

Considere seu público e tente pensar no que eles precisam.

Uma outra coisa a acrescentar é o suporte novo ou descontinuado para determinadas plataformas. (Por exemplo, deixamos o suporte para o Win3.1 e adicionamos o Vista 64 bits).

Answer 2

Eu daria uma olhada nas notas de lançamento de projetos populares de f/oss:

• Raposa de fogo
• Gimp
• Ubuntu
• Android
• Teamcity
• etc.

Todos esses projetos têm notas de lançamento bastante legíveis e equilibradas.

Answer 3

Se você possui um sistema de gerenciamento de projetos/rastreamento de problemas, definitivamente deve usar isso para gerar suas notas de lançamento. Trac e Redmine Em particular, são muito bons nisso.

Os pontos de liberação devem ter algumas propriedades, IMO:

• Lembre -se do seu público. Se este é um aplicativo para iPhone, poucos se importarão com o fato de que um erro lógico específico na linha 572 na classe Foo foi corrigido. Mas eles se importam muito com "o aplicativo agora é sensível ao acelerômetro".
• Resuma os novos desenvolvimentos, recursos e bugs de uma maneira ampla e abrangente, se possível. Se você pode unir isso tematicamente (por exemplo, "implementamos genéricos e tipos anônimos"), uma pequena sinopse sobre isso é uma boa maneira de dar às pessoas o quadro geral.
• Demeque as coisas específicas corrigidas, com links para o seu rastreador de insetos públicos, se houver. Isso geralmente pode ser gerado automaticamente.
• Não forneça detalhes excruciantes. Resumos de um ou dois liners de cada coisa que foram adicionados ou fixos devem ser suficientes.
• Sempre inclua identificadores de liberação específicos (por exemplo, "v.1.4.5"), conforme apropriado.

Answer 4

Realmente depende do público. Para usuários técnicos (por exemplo, desenvolvedores que usam sua API), você pode ser muito técnico. Por outro lado, os usuários finais de alto nível de um aplicativo que você criou pode estar interessado apenas em novos recursos e grandes alterações.

Entre os usuários não técnicos, também precisam dos detalhes, por exemplo, departamento de suporte. Para as pessoas, você pode dar uma descrição detalhada sem as especificações técnicas de baixo nível, por exemplo, "corrigiu um bug em que o registro não foi salvo no banco de dados".

Answer 5

Uma prática recomendada com notas de lançamento na minha opinião é a automação. Se houver certas práticas recomendadas para o sistema de controle de revisão, envie mensagens (http://drupal.org/node/52287), você pode criar notas de lançamento por um script automatizado (http://cvs.drupal.org/viewvc.py/drupal/contributions/tricks/cvs-release-notes/). Isso criaria Notas de lançamento realmente boas: http://drupal.org/node/226165

Answer 6

O principal colaborador das notas de lançamento seria sua equipe de desenvolvimento. É uma boa prática permitir que seus desenvolvedores e testadores capturem qualquer informação relacionada ao Notes de liberação contra seus trabalhos vinculados a alterações no TFS.

Então você pode usar o projeto de código aberto como http://tfschangelog.codeplex.com Para gerar notas de liberação. Possui versão da GUI e uma versão da linha de comando que facilita a agenda de seus relatórios de notas de lançamento noturno.