Si está utilizando maven, existe un complemento maven changes para este propósito y la producción de este informe podría automatizarse fácilmente en un proceso de integración continua.

Si usas JIRA (lo cual sugeriría de cualquier manera), puede generar automáticamente las notas de la versión para ti. El formato incorporado es bastante simplista, pero funciona bien en muchos casos. El contenido es personalizable hasta cierto punto, aunque esta no es la palabra definitiva en términos de flexibilidad.

Si busca mejores notas de la versión de JIRA, pruebe el complemento PDF View. It:

• más que una lista de "problemas completados" sin procesar (por ejemplo: instalación y actualización instrucciones, detalles legales, pruebas ejecutadas, archivos modificados)
• más control sobre lo que se incluye (excluyendo ciertos estados, resoluciones, tipos de problemas, etc.)
• permite distribuir su documento de Notas de la versión en correo electrónico (formato PDF) o impreso en papel

Descargo de responsabilidad: Soy un desarrollador de este complemento comercial de JIRA.

Estoy luchando con los mismos problemas. En nuestro desarrollo utilizamos svn / jira y tenemos una herramienta personalizada que intentará construir y probar los cambios antes de que se confirmen, y el desarrollo ingresa el número de jira como parte de ese proceso (valida el número). Este número de jira se incluye en el SVN commit

A partir de entonces generamos una nota de lanzamiento entre dos puntos en svn y a partir de los comentarios en cada commit podemos construir una lista de problemas que se han rellene la nota de lanzamiento.

El problema con esto es que 1. los problemas en la nota de la versión deben introducirse como cambios de código. No se incluyen los problemas solucionados sin un cambio de código. 2. Si un desarrollador está a mitad de camino a través de una solución, aparecerá en las notas de la versión cuando mayo no debería.

Quiero encontrar una solución con una sobrecarga manual mínima donde podamos tomar cualquier compilación de nuestro sistema de CI y convertirla en una versión.

Estoy considerando adaptar el proceso para que el release note generate fallará si un problema no se cierra, pero los desarrolladores se quejarán de que podrían estar a mitad de camino cuando queramos hacer una versión.

La otra opción es incluir solo los problemas completados en la nota de publicación. Sin embargo, el problema con eso es que si un desarrollador realiza una corrección en la versión A, pero no cerró el problema en el momento en que se liberó A, y luego no realizó cambios de código y cerró el problema después de que se liberara A, ¿cómo puedo incluir ahora automáticamente este problema en las notas de la versión (Puede ser que podría buscar todos los jiras cerrados entre la versión A y B....)

Gracias por leer

En mi empresa usamos bugzilla. Usamos el hito para etiquetar un error con un número de versión específico. Luego generamos un informe xml para todos los errores con un hito específico y usamos un pequeño script para generar las notas de la versión a partir de él.

Esto es algo que puede generalizarse fácilmente a cualquier software de seguimiento de errores, en general.

Supongo que también podría estar vinculado a los comentarios en los mensajes de confirmación en su sistema de control de versiones. Se podría hacer una consulta para listar todos comenta en el control commits en verson y luego filtra todos los comentarios con una etiqueta específica.

Suponiendo que los desarrolladores no son privateers y son parte de un equipo que obtiene asignaciones y las hace, una lista de lo que se hizo y debe ser parte de UAT es la nota de liberación de facto. Las listas de cambios de archivos y similares son irrelevantes y pueden extraerse trivialmente del control de código fuente.

Dado que es dolorosamente difícil hacer cumplir una política de desarrolladores que comprueban el código con números de problema, no me molesto. Pregunto sobre ello en la revisión del código. También tengo una lista de lo que estamos trabajando en. El material que está hecho-hecho se agrega al registro justo antes de que se ejecuten los comandos mvn release:prepare. Luego lo camino hacia el QA y UAT.

No es probable que esto se amplíe a cientos de números por semana. En esos casos, es probable que sea preferible un sistema más robusto.

Podría usar una herramienta como doxygen para hacer esto, pero es un poco tedioso comentar la forma en que doxygen espera. Normalmente las recibo a mano.

No estoy seguro, pero ¿algo como FogBugz también haría esto?

Para aquellos que trabajan con.NET y TFS, puede usar TfsChangeLog para generar automáticamente sus notas de la versión.

El registro de cambios de TFS permite a los usuarios de Team Foundation Server (TFS) extraer información relacionada con Conjuntos de cambios y WorkItems asociados en formato XML que se transforma en HTML. TFSChangeLog produce automáticamente el Registro de cambios / Notas de la versión en función del rango de conjuntos de cambios seleccionado.

TFS mantiene el historial de versiones de archivos a través de conjuntos de cambios registrados y WorkItems asociados. Esta información exacta se utilizará para generar notas de la versión. Configuration / Release manager puede usar campos de datos del sistema o campos personalizados con el propósito de generar contenido de notas de la versión. Potente soporte XSLT 2.0 para la transformación de datos desde el formato XML raw se proporciona fuera de la caja que sin duda abre la posibilidad de generar datos en varios formatos. El soporte para XSLT 2.0 hace que sea muy fácil aplicar condiciones de filtrado para la salida de transformaciones como requerido por los usuarios.

Me enfrenté a un problema similar recientemente y mejoré un plugin maven existente para hacer esto.

Si usas Git para el control de código fuente y construyes tu proyecto usando Maven, entonces esta puede ser una buena solución: https://github.com/pankajtandon/maven-git-commit-id-plugin#releasenotes