Ченджлог — это способ сообщить пользователям вашей разработки о всех внесенных вами изменениях. Обычно ченджлог применяют в том случае, если проект ведется с применением Git.
Необходимость заявлять о внесенных изменениях очень индивидуальна, и нет каких-либо жестких аргументов в пользу или против этого.
Ченджлог как он есть
По сути, ченджлог — это всего лишь файл, в который упорядоченно вносятся все изменения в проекте. Обычно такой файл создают и соотносят с каждой новой версией программного продукта, где прописывается, что было изменено, добавлено или удалено.
Различают 2 способа создать ченджлог:
Ручной — это когда создается обычный текстовый файл, где «руками» вписываются все изменения в проекте с указанием дат и причин изменений.
Автоматический — это когда ченджлог генерируют из сообщений коммитов.
Есть ли реальная необходимость в ченджлоге
Многие задают себе этот же вопрос, чтобы понять, имеет ли смысл тратить свое время на его создание.
Ченджлог — это журнал изменений в проекте, и он может быть интересен вашим пользователям, другим разработчикам и даже вам через какое-то время. Ченджлог дает возможность просмотреть, как изменялся и развивался проект с течением времени. Возможно, не всем, но некоторым людям такая «история» действительно интересна.
Ченджлог — это не требование, а скорее, акт доброй воли, чтобы удовлетворить желание пользователей узнать о вашем проекте немного больше.
Обычно если проект «открытый», то файл ченджлог всегда можно найти в его GIT-репозиториях. Есть ли необходимость в таких файлах? Скорее да, чем нет. Ченджлог не сделает ваш проект лучше или хуже, но точно прибавит лояльности от тех людей, которые интересуются вашим проектом чуть больше, чем остальные.
Где располагаются ченджлог-файлы
На самом деле, ченджлог очень распространен и представлен в различных вариациях, поэтому подобные файлы можно встретить в разных проектах: и в веб-программах, и в играх, и в мобильных приложениях. Вот лишь несколько мест, в которых можно встретить ченджлог:
в одном из постов вашего любимого блога, когда изменения блога «выносят» в отдельный пост;
на GitHub в файле changelog.md, если проект открытый и располагается на этом ресурсе;
в специальном разделе «changelog» на веб-сайте вашей любимой программы;
на страницах ваших мобильных приложений в разделе «ченджлог» или «что нового?»;
и другие места.
Заключение
Ответить на главный вопрос этой статьи: «Нужен ли ченджлог?» можно следующим образом. Ченджлог берет свое начало еще с тех времен, когда файлы сайта пересылались от разработчика к разработчику по электронной почте. На тот момент наличие файла «changelog» в папке с проектом было необходимостью, потому что именно по этому файлу новый разработчик мог быстрее понять и разобраться, как развивался проект, что нужно сделать и т. д. Благодаря такому файлу новый разработчик быстрее приступал к работе.
Но времена поменялись, и совместной разработкой над одним программным продуктом теперь никого не удивишь, а сервисы наподобие GitHub очень популярны среди разработчиков. Если ваш открытый проект расположен на GitHub (и др.), то у вас уже фактически есть лог-файлы, которые при желании можно прочитать. Вот и получается, что те, кому нужно подробнее узнать о проекте, могут прочесть лог-файлы. А те, кто не смогут прочесть лог-файлы, также не смогут прочесть и ченджлог, тем более если он сгенерирован автоматически.
Когда ченджлог пишется в ручном режиме, это уже больше похоже на простую статью из категории «Новости проекта» — такой формат еще долго будет востребован, так как он дает возможность узнавать об изменениях интересующего их продукта и написан более простым и понятным языком.
Вот и получается, что современный ченджлог немного потерял свою значимость и функциональность, если сравнивать его с ченджлогом 20-тилетней давности. Это произошло из-за ресурсов, где можно разместить свой проект и где практически любой может прочитать файлы проекта, при этом сами ресурсы предлагают альтернативы традиционному ченджлогу. Однако ченджлог — это дополнительный канал коммуникации со своими пользователями, который точно не нужно упускать, если вам дорог каждый пользователь вашего программного продукта.
Другое
