Нужен ли ChangeLog?

Это, если вносяться специальным образом. Автоматические сообщения вроде merge branch тоже не говорящие. Может быть, что изменения откатываются или переписываются между релизами, тогда та информация уже не нужна. Изменения не группируются при смене версии.

News не нужен.

Нужен только Changelog.

моё мнение что не разработчикам хеллоувордов решать, что должно быть, а чего не должно быть, тем более если они понятия не имеют, о чем идёт речь. в ChangeLog вносятся все изменения, прошедшие QA и на него QA ориентируется, когда делает тест-план релиза. а News — это да, какая-то херня для новостей на ЛОРе, можно и без неё.

News — это да, какая-то херня для новостей на ЛОРе, можно и без неё.

+1.

лучше следовать традициям

в ChangeLog вносятся все изменения, прошедшие QA и на него QA ориентируется, когда делает тест-план релиза

Это в идеальном мире розовых пони и большого бабла.

А на практике у большинства разработчиков обычно так: бабла нет, QA нет, релиз подготовливают по принципу «ну вроде в багтрекере ничего blocking не осталось, можно выпускать».

а News — это да, какая-то херня для новостей на ЛОРе, можно и без неё.

«Мы выпустили 3.4.5. Хз, что там нового. Скачивайте, сами смотрите.»

Внезапно, софт разрабатывается для пользователей, а не ради зарплаты разработчика.

Тоже видать хеллоувордщики:

https://github.com/GNOME/gtk/blob/master/NEWS

https://wiki.documentfoundation.org/ReleaseNotes/7.0

https://releases.llvm.org/10.0.0/docs/ReleaseNotes.html

Мы выпустили 3.4.5. Хз, что там нового. Скачивайте, сами смотрите.»

Мы выпустили gcc 10.2: https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=10.2

Мы выпустили Visual Studio 2019 Version 16.8 Preview 1: https://developercommunity.visualstudio.com/topics/Fixed+In%3a+Visual+Studio+2019+version+16.8+Preview+1.html?sort=votes

как-то так.

А на практике у большинства разработчиков обычно так: бабла нет, QA нет, релиз подготовливают по принципу «ну вроде в багтрекере ничего blocking не осталось, можно выпускать».

разработчики хеллоувордов опять выходят на связь

Ути-пути, настоящий разработчик! Он у вас породистый? Смотри не лопни от ЧСВ :)

sort=votes

Очень информативно. Социалочка.

Мы выпустили gcc 10.2

И видим там в первую очередь кучу исправленных регрессий, пойманных при тестировании. Очень информативно.

Вопрос: кому это надо?

Это, если вносяться специальным образом. Автоматические сообщения вроде merge branch тоже не говорящие. Может быть, что изменения откатываются или переписываются между релизами, тогда та информация уже не нужна. Изменения не группируются при смене версии.

См., например, NEWS gtk — отдельно фичи по категориям, отдельно исправленные баги списком. Там всё, что идёт в релиз.

Классический Change Log — это вот:

2008-09-17  Matthias Clasen  <mclasen@redhat.com>

        * configure.in: Bump version

        * === Released 2.14.2 ===

        * NEWS: Updates

2008-09-17  Matthias Clasen  <mclasen@redhat.com>

        Bug 346903 – gtk_enumerate_printers needs events to complete

        * gtk/gtkprintbackend.h:
        * gtk/gtkprintbackend.c: Add a GtkPrintBackend::status property.

        * modules/printbackends/cups/gtkcupsutils.h:
        * modules/printbackends/cups/gtkcupsutils.c: Turn the connection
        test into a tristate available/unavailable/in progress.

        * modules/printbackends/cups/gtkprintbackendcups.c: Use a single
        connection test instance for getting the default printer and for
        getting the printer list. Set the GtkPrintBackend::status property
        according to the result of the connection test. Use the printer-type
        attribute to find the default printer, if cups supports it.

        * gtk/gtkprinter.c: When enumerating printers, give up when
        the backend status is 'unavailable'.

        * gtk/gtkprintunixdialog.c (printer_status_cb): Select the printer
        when it is the default and nothing else has been selected yet.

        Patch by Marek Kasik.

2008-09-17  Christian Persch  <chpe@gnome.org>

        Bug 552668 – format not a string literal and no format arguments in
        gtkimmodule

        * gtk/gtkimmodule.c: (gtk_im_module_load): Use %s with g_warning here.

Зачем нужно знать, какой датой и каким авторством прошло то или иное изменение, если при необходимости эту информацию легко найти в логе VCS?

Это тупо git log на коленке.

ChangeLog — атавизм той эпохи, когда VCS не применялись повсеместно, а патчи пересылались исключительно почтой от одного разработчика другому.

Под словом Changelog можно понимать несколько разных вещей с совершенно разными целями.

Changelog который публикуется в новостях о релизе ориентирован на пользователей а не на разработчиков, поэтому, во-первых, он в большинстве случаев не предполагает, что читатель знаком с используемой в проекте VCS и вообще имеет к ней доступ.

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

Поскольку git log - вещь неизменяемая, то запись в нём о том что баг X пофикшен не значит по сути ничего. Тремя месяцами позже в том же git log может оказаться запись по типу «Мы думали что баг X пофикшен, но ошибались, и теперь наконец пофиксили его окончательно».

Поэтому сырой git log не подходит на роль отчета о проделанной работе за некоторый период. Пользователю нужно понимать результат, а не всю многосерийную историю взаимоотношений разработчиков с багами.

При этом никто не мешает генерировать Changelog из лога коммитов в vcs, отфильтровывая лишнее типа «поправил форматирование», «переделал тестовый фреймворк» или «пофиксил предыдущий фикс», группируя коммиты по bug id и записывая результат в подходящий формат.

https://keepachangelog.com/

Из-за таких любителей традиций, нормальным людям до сих пор приходится мучатся с autotools.

Из-за таких любителей традиций, нормальным людям до сих пор приходится мучатся с autotools.

autotools прекрасный фреймворк. Перевёл свои проекты на него обратно с cmake — перестала болеть голова.

Сказала, как боженька.

В целом согласен.

Однако мне импонирует подход GNOME, где пишут для пользователя максимально подробные release notes в файле NEWS, а Change Log выкинули за ненадобностью.

История изменений:

1. Добавили фичу А;
2. Переделали фичу А;
3. Исправили найденные ошибки реализации фичи А;
4. Изменили название фичи с А на Б, чтобы новое название лучше отражало суть;
   …
5. Приняли сторонние патчи для фичи Б.
6. Релиз.

Ченджлог релиза:

1. Добавили фичу Б.

Новость:
Мы рады представить новую версию с реализацией фичи Б, которая выглядит так, потому что… Спасибо за её реализацию следующим людям…

Ну в таком случае они не выкинули Changelog, они его переименовали в NEWS.

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

Генерирование NEWS автоматически - это обычно не от хорошей жизни делается, а говорит о недостатке времени на оформление нормальных новостей.

Но тут ещё стоит отметить что файл CHANGELOG.TXT в репе проекта - это действительно проблемное место, если его требуют наполнять по ходу дела, а не в момент выхода релиза.

Такой файл сильно мешает параллельной разработке, и он как раз и является атавизмом, который надо убирать. Или например changelog-секция в rpm-спеках, третий год уже обсуждаем как его выпилить.

Но тут виноват не Changelog как идея, а форма, в которой он пишется.

А у других начала.

Комментарии в коде тоже не нужны.

Да, комментарии вида

/* let’s assume we return 0 */ int ret = 0;

не нужны.

С другой стороны, big theory statement, о том как это вообще работает, очень приветсвуются. И да, табличка сарказм не нужна.

Гномосеки-то? Однозначно, для любого отличного от Hello World проекта с GTK разработчику нужно много вазелина. Про вторых не знаю, третьи едут только за счёт кучи влитых в них денег.

Ты ещё бы привёл в пример GNU, у них так вообще GNU Hello есть. Такой хелловорлд долгострой, который 28 лет пилится.

У нас changelog генерится из истории git автоматически. Мы не мержим, а ребейзим и у нас один коммит – одна таска, так что история линейная и чёткая. С нашей частотой релизов по-другому и никак.

Ну cmake так-то тоже невнятное говно. Лучше конечно, но всё равно отбитое наглухо.

Это проблемы всех проектов в начальной стадии, changelog важен, чтобы показать, что где-то сделали не тот выбор, а теперь то всё ровно.

для любого отличного от Hello World проекта с GTK разработчику нужно много вазелина

Ну там же куча вариантов «для людей» - от wx до java.

Vcs это для разработчиков.

ChangeLog это для пользователей.

Если вы в состоянии вести описание коммитов так чтобы из него вы при формировании релиза могли с легкостью сгенерить ChangeLog - пожалуйста.

Заставлять пользователей читать коммитлоги и вообще разбираться с какой либо vcs(это инструмент разработки, на минуточку) это бред

Вот, этот юзер в теме, писать красивый код это пол дела, суметь release engineering очень важно.

News не нужен. Нужен только Changelog.

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

Традиционный подход:
- В 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.

https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs

Это стандартный для GNU подход, он же конченный.

это конченый подход

Это ГНУтый конченный подход.

Нужен ли ChangeLog?

Нужен </thread>

Теорема Эскобара, да. Вся надежда на meson.

Нужен ли ты, дебил?

Хук, дергающий ‘git log > ChangeLog’ при make dist

а точно пилится? паследний релиз годков 6 как был. может оно уже готово )

Далеко не все пользуются системами контроля версий. Некоторые их принципиально не любят. Например автор 7zip

Changelog желателен, нужен. Не обязательно прям каждый пук и хрюк описывать, но все важнейшие изменений или ключевые модификации, новые функции крупные - указать ннада

Лорчую, сто коммитов - 1 фича, ее можно и нужно описать

git log

Не нужно, git не стандарт. Его нельзя гарантировать

NEWS

Это просто краткая выдержка, полезно и удобно, но вообще не обязательно на грани с ненужно

VCS

Может быть, а может и не быть.

ChangeLog

Нужно, хотя порой там пишут бред и можно текст перенести в NEWS

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

А на практике у большинства разработчиков обычно так: бабла нет, QA нет, релиз подготовливают по принципу «ну вроде в багтрекере ничего blocking не осталось, можно выпускать»

Не можешь срать — не мучай жопу. Не можешь сделать релиз — нечего пытаться делать Changelog.

Далеко не все пользуются системами контроля версий. Некоторые их принципиально не любят. Например автор 7zip

Я не люблю, но пользуюсь. Если над проектом работает 1-2 человека и нет ветвей релиза, то контроль версий не нужен — так я делаю для каких-то мелких или просто личных софтин. У меня вон индус в команде вынес сотню строк у отдельную репу git, в итоге там единственный коммит — ну и зачем он это сделал? А низачем, просто карго культ.