Руководство по написанию changelog

Этот документ описывает рекомендуемые правила оформления секций %changelog и объём включаемой в них информации.

Используемые понятия

Пример секции:

* Wed Apr 02 2008 Andrey Rahmatullin <wrar@altlinux> 4.6.2-alt7.pre1
[ Andrey Rahmatullin ]
- syntax:
  + recognize .hh and .hpp as c++ again
  + recognize man pages with additional suffixes other than 'x', such as
    write.3p (Debian)

[ Vladislav Primerov ]
- make visible_tabs and visible_tws mcedit options configurable through config
  file (Debian)

[ Alexander Sluchainyi ]
- specfile cleanup

* Sat Mar 29 2008 Andrey Rahmatullin <wrar@altlinux> 4.6.2-alt6.pre1
- build with slang2

Здесь всё, что относится к сборке 4.6.2-alt7.pre1, будем называть записью, имя в квадратных скобках - группой, текст, начинающийся с дефиса («- make visible_tabs and visible_tws mcedit options configurable through config file (Debian)») - пунктом, текст, начинающийся с плюса («+ recognize man pages with additional suffixes other than 'x', such as write.3p (Debian)») - подпунктом, одну строку файла спека («- make visible_tabs and visible_tws mcedit options configurable through config») - строкой.

Синтаксис чейнджлога

• (Опциональная) группа состоит из имени в квадратных скобках и начинаются с первой позиции строки.
• Пункт верхнего уровня начинается с 1-й позиции в строке и состоит из дефиса, пробела и собственно текста.
• Подпункт начинается с 3-й позиции в строке и состоит из плюса, пробела и собственно текста.
• Строки переносятся по словам и содержат не более 78 символов. При этом текст новой строки выравнивается по началу текста предыдущей (т.е. 3-я позиция для пунктов верхнего уровня и 5-я для подпунктов).
• Начинать новую строку с символа # нельзя (такая строка будет воспринята как комментарий).

Пример:

- syntax:
  + recognize .hh and .hpp as c++ again
  + recognize man pages with additional suffixes other than 'x', such as
    write.3p (Debian)
- make visible_tabs and visible_tws mcedit options configurable through config
  file (Debian)

Содержимое

• Чейнджлог (обязательно!) пишется на английском языке.
• При сборке новой upstream-версии это указывается первым пунктом.
  • При сборке из снэпшота системы контроля версий необходимо указать информацию, позволяющую идентифицировать это снэпшот (дата и время для CVS, ревизия SVN, 8 первых символов идентификатора коммита для git, mtn, bzr, hg, либо вывод git-describe для git).
• Если в сборке версии существенно принимало участие более одного человека, то изменения, вносимые разными людьми, собираются в группы по авторам, иначе группы не нужны.
• Если новая сборка содержит исправленные по сравнению с предыдущей сборкой ошибки безопасности, эти ошибки указываются отдельным пунктом (пример: "security fixes (CVE-0001, CVE-0002)").
• Изменения, произведённые апстримом (кроме исправлений ошибок безопасности), в чейнджлоге не указываются (для этого есть чейнджлоги апстрима, зачастую включаемые в пакет).
• Косметические изменения спек-файла, не влияющие на получаемый пакет, указываются максимум одной строкой, либо не указываются вовсе. Это не относится к исправлениям тега License, изменениям параметров сборки и т.д.
• Исправления, необходимые для успешной сборки, соответствия требованиям ALT Linux и т.д., не указываются, если они были сопряжены с упаковкой новой версии и для старой версии были не нужны (эти исправления - адаптация новой версии, т.е. часть процесса её упаковки). Если же они были вызваны изменением требований либо окружения, желательно это указать (пример: "fix building with new autotools").
• Если .spec-файл адаптирован из другого дистрибутива, то старые записи %changelog обязательно должны быть сохранены (записи в %changelog фактически являются информацией об авторских правах на спек, и их недопустимо выкидывать в производной от исходного спека работе).
• Используйте спеллчекер :)

Указание источников и контекста

• Если изменение взято извне либо основано на взятом извне, в соответствующем изменению пункте чейнджлога в скобках указывается источник. Это может быть название дистрибутива/репозитория, название внешней BTS и номер бага в ней, ID участника ALT Linux Team или произвольное указание на человека или сайт. Здесь под изменением подразумевается готовый патч, адаптированный патч или иные аналогичные указания.

Примеры:

- move global configs to /etc (RH)
- linked libnetpbm.so against -lm (RH #165980)
- use optflags (drool@)

• Если изменение связано с багом в багзилле ALT Linux, номер бага указывается в скобках в соответствующем пункте. Это может быть совмещено с предыдущим требованием. Синтаксис такого рода помещает (точнее, будет помещать после введения в строй соответствующей инфраструктуры) в указанный баг оповещение о том, что такой пакет вышел.

Примеры:

- add option to build with libslang2 (#10591)
- recognize .3gp as video, not manpage (#14982, hiddenman@)

• Специальный синтаксис (Closes: #12345, #6789) закрывает (точнее, будет закрывать после введения в строй соответствующей инфраструктуры) все упомянутые в скобках баги в багтракере при прохождении пакета в Сизиф.

Пример:

- Fixed segfault on exit (Closes: #66666)

• Номера багов в скобках разделяются запятыми.

Лучшие практики оформления changelog

• Если changelog пакета оформлен единообразно, не нарушайте это единообразие (если оно не противоречит этому policy). Если же changelog хаотичен или противоречит нормативной части этого policy, то оставленный перед changelog комментарий о стиле ведения changelog с текущей версии поможет избежать продолжения хаоса в будущем.
• Старайтесь, чтобы все предложения в changelog были в одной форме ("fix memory leaks", "fixed memory leaks", "memory leaks fixed", но не смесь разных форм в одной записи), в таком виде их гораздо удобнее читать.
• Единообразно оформляйте предложения changelog'а: либо начинайте, либо не начинайте их все с большой буквы; либо заканчивайте, либо не заканчивайте их точкой.
• Группировка сходных пунктов в подпункты позволяет уменьшить размер changelog'а и улучшить его читаемость.

Разное

• Для форматирования changelog существует команднострочная утилита add_changelog, а также макросы для Vim и Emacs.
• Пример хорошего changelog'а