История изменений
Исправление slovazap, (текущая версия) :
Традиционный подход:
- В NEWS перечисляются важные изменения от релиза к релизу.
- В ChangeLog перечисляются ВСЕ изменения в исходном коде.
Это не традиционный подход, это конченый подход. Всего в паре проектов такое видел, к счастью. Наиболее распространённый подход - когда таки ведут файл с резюме изменений в привязке к релизам. Он может называться и NEWS и ChangeLog, понятно что присутствует только один из этих файлов. А хранить в файле лог VCS - так только имбецилы могут делать.
Тарболы нужны только для поставки софта в дистрибутивы, чтобы сборочной машине не приходилось тянуть файлы из VCS (что банально занимает больше времени).
Нет. Большинство мест которые хостят VCS позволяют скачать тарболл сразу из тэга или любого коммита, так что руками их готовить в большинстве случаев не надо. Редкий случай когда этом может иметь смысл - когда у вас готовятся промежуточные данные которые требуют тяжелых зависимостей, и хочется сгенерировать их заранее - например, в репе документация в LaTeX, а в тарболл кладутся готовые pdf. Или в репе .blend, а в тарболле готовые рендеры. Также раньше в тарболл клали сгенеренные configure и Makefile.in. Но вообще (может за исключением .blend) это порочная практика, правильные дистрибутивы весь этот нагенерённый мусор выкинут и сгенерируют сами. Много где есть жёсткие полиси на эту тему.
Имеет смысл писать только осмысленные записи в NEWS. Все, кого интересуют мелкие детали, могут прочитать git log самостоятельно. А кто не может этого сделать, тем содержимое файла ChangeLog всё равно ничего не скажет.
Так и есть. Только всю жизнь то что вы имеете в виду под NEWS ChangeLog'ом и называли. `NEWS` (`AUTHORS`, `INSTALL`, `BUGS`, `COPYING`) это стиль GNU'шной шушары, а современный стиль это `README.md`, `CHANGELOG.md` и `LICENSE`/`LICENSE.md`. В CHANGELOG естественно краткое описание изменение в релизе, а не vcs log.
Исходная версия slovazap, :
Традиционный подход:
- В NEWS перечисляются важные изменения от релиза к релизу.
- В ChangeLog перечисляются ВСЕ изменения в исходном коде.
Это не традиционный подход, это конченый подход. Всего в паре проектов такое видел, к счастью. Наиболее распространённый подход - когда таки ведут файл с резюме изменений в привязке к релизам. Он может называться и NEWS и ChangeLog, понятно что присутствует только один из этих файлов. А хранить в файлк лог VCS - так только имбецилы могут делать.
Тарболы нужны только для поставки софта в дистрибутивы, чтобы сборочной машине не приходилось тянуть файлы из VCS (что банально занимает больше времени).
Нет. Большинство мест которые хостят VCS позволяют скачать тарболл сразу из тэга или любого коммита, так что руками их готовить в большинстве случаев не надо. Редкий случай когда этом может иметь смысл - когда у вас готовятся промежуточные данные которые требуют тяжелый зависимостей, и хочется предподготовить их - например, в репе документация в LaTeX, а в тарболл кладутся готовые pdf. Или в репе .blend, а в тарболле готовые рендеры. Также раньше в тарболл клали сгенеренные configure и Makefile.in. Но вообще (может за исключением .blend) это порочная практика, правильные дистрибутивы весь этот нагенерённый мусор выкинут и сгенерируют сами. Много где есть жёсткие полиси на эту тему.
Имеет смысл писать только осмысленные записи в NEWS. Все, кого интересуют мелкие детали, могут прочитать git log самостоятельно. А кто не может этого сделать, тем содержимое файла ChangeLog всё равно ничего не скажет.
Так и есть. Только всю жизнь то что вы имеете в виду под NEWS ChangeLog'ом и называли. `NEWS` (`AUTHORS`, `INSTALL`, `BUGS`, `COPYING`) это стиль GNU'шной шушары, а современный стиль это `README.md`, `CHANGELOG.md` и `LICENSE`/`LICENSE.md`. В CHANGELOG естественно краткое описание изменение в релизе, а не vcs log.