Автоматическое создание чтения «Что нового в этой версии»

Question

Мы все это знаем - это чтение, в котором перечислены изменения, вносимые каждой новой версией нашего любимого программного обеспечения. Всякий раз, когда он поставляется в виде файла ( Changes.txt , CHANGES , WhatsNew.txt и т. Д.) Или представлен в установщике, обычно это первое читаем перед установкой / обновлением.

В текущем проекте у нас есть файл Changelog.txt , который обновляется вручную каждый раз, когда происходит заметное изменение. Однако это часто приводит к «я забыл обновить журнал изменений». Поэтому я ищу способ автоматизировать это.

Я имею в виду сценарий, который извлекает изменения из наших сообщений фиксации (используя соглашение) и генерирует файл. Например сообщение коммита типа

Обновлен json-glib до 0,7,6

[изменения]

- Исправлено падение в Windows

- Исправлены проблемы с контактами в Facebook с очень большими UID.

выдаст следующее Changes.txt

Версия 1.9.18 (10.10.2010)

• Исправлено падение в Windows
• Исправление проблем с контактами в Facebook с очень большими UID.

Кто-нибудь знает лучшее решение / инструмент для этого или я напишу свое собственное?

Спасибо!

Answer 1

Я думаю, что журнал изменений должен фиксировать только основные изменения / исправления дефектов в выпуске. Поместить все в список изменений не имеет смысла вообще. Это делает журнал изменений нечитаемым и в конечном итоге становится бесполезным.

Создание журнала изменений из комментариев в списке изменений может также привести к утечке деталей реализации вашего приложения конечному пользователю.

Как правило, в выпуске есть 2 типа разработки, с точки зрения предоставления пользовательской ценности:

1. Новая функция
2. исправление дефектов, которые имеют большое влияние.

Я полагаю, что содержание выше должно быть достаточно для журнала изменений. Такие изменения, как «рефакторинг кода», могут принести пользу разработчикам, но ничего не значат для конечного пользователя, поэтому не должны появляться в журнале изменений.

Для новой функции, как правило, мы можем отследить ее по документу проекта, который в итоге будет перенесен в новый список функций.

Я уверен, что для устранения дефектов вы используете какую-то систему отслеживания дефектов. Отметьте эти существенные дефекты с помощью определенного тега. И вы можете сделать запрос для этих дефектов, который был закрыт с момента последнего выпуска.

Надеюсь, это поможет.

Answer 2

Вы можете автоматически сгенерировать его из описаний в вашей системе отслеживания ошибок для ошибок, помеченных как исправленные в этой версии. Если вы отличаете ошибки от запросов функций, вы можете пометить это тоже.

Я использую MantisBT для ошибок, и это автоматически сгенерирует список изменений для вас из коробки.

Answer 3

Нет лучшего способа быть уверенным в том, чтобы охватить все, что я знаю. То есть при условии, что вы можете заставить всех писать коммит-сообщения, которые имеют смысл.

Mercurial и Subversion, например, особенно подходят для последующей обработки журнала фиксации: mercurial, потому что он может легко настроить способ отображения журнала, используя механизм шаблонов и Subversion, поскольку он может создавать дамп войдите в .xml, который затем можно будет относительно легко обработать для создания первого черновика журнала изменений.

Answer 4

Если вы не хотите, чтобы ваш клиент видел список всех проблем, которые были устранены (вероятно, нет), вы можете определить поле с именем include в поле changelog в ваш инструмент отслеживания проблем, который вы выбрали, и автоматически генерировать документ, включающий только эти поля.

Сюда обычно входят проблемы, о которых сообщает клиент, и, возможно, важные новые функции.