Если классическая семантическая схема управления версиями «MAJOR.MINOR.PATCH» имеет смысл, зависит от того, кого вы развертываете, и особенно, когда и как часто вы развертываете для конечного пользователя . Схема наиболее полезна, если вы работаете со стабильным выпуском «4.5», где вы начинаете с 4.5.0. Версии 4.5.1, 4.5.2 и т. Д. Содержат только исправления ошибок, в то время как вы внутренне уже работаете над версией 4.6.
Например, если вы предоставляете «стабильную ветвь» своему конечному пользователю, предоставьте ему версию 4.5.0 для первоначального развертывания и 4.5.1, 4.5.2 при каждом выпуске исправления. В вашей внутренней «гибкой» разработке и развертывании в середине спринта у вас уже может быть версия 4.6, просто назовите ее «бета-версия». Всякий раз, когда вы развертываете его в середине спринта, добавьте автоматически сгенерированный номер сборки, например «4.6.beta build 123». Когда ваш спринт заканчивается, присвойте ему «4.6.0» и переключите номер версии для следующего спринта внутри на «4.7». Начиная с «.0» - это всего лишь соглашение, вы также можете использовать «.0» для маркировки бета-версий и начинать с «.1» для своих конечных пользователей. ИМХО слово «бета» гораздо выразительнее, говорит всем, что спринт «еще не закончен».
Если вы выпускаете полный журнал изменений для конечного пользователя с каждой бета-версией, зависит от вас, но по крайней мере в конце спринта журнал изменений должен быть завершен, и всякий раз, когда вы предоставляете исправление для конечного пользователя, вы также должны обновить исторические документы.
Вы найдете стратегию выпуска двух отдельных веток, одной "стабильной" ветки с семантическими номерами версий и "ветки разработки", помеченной номерами сборки или чем-то подобным, во многих продуктах с открытым исходным кодом, таких как Inkscape, Firefox или 7-zip.
Однако, если вы не работаете с отдельными стабильными ветвями и ветвями разработки и выпускаете новую версию для своего конечного пользователя ежедневно, вам также следует ежедневно увеличивать номер версии. В таком случае номера версий «4.5.1», «4.5.2», ..., вероятно, будут отражать ваши индивидуальные развертывания и не будут указывать на разницу между исправлениями ошибок и другими изменениями. Это может быть хорошо, это просто больше не классическая "семантическая версия". В этом сценарии вы также можете развернуть версии 4.5, 4.6, 4.7, 4.8, что не дает реальной разницы.
Относительно вашего вопроса о записях в вашем журнале изменений: ИМХО, когда что-то видимо конечному пользователю, стоит внести запись в журнал изменений, как только вы развернете изменение. Например, если вы используете переключатели функций и вносите изменения в некоторые недоделанные функции, которые еще не активированы для пользователя, это не входит в список изменений. Если вы выполняете только рефакторинг без видимых изменений для пользователя, это не входит в список изменений. Если вы исправите ошибку, которая могла повлиять на некоторых пользователей, это определенно входит в список изменений - и об этом следует упомянуть в то же время, когда вы устанавливаете исправление. И не имеет значения, выпускаете ли вы ежедневно, ежемесячно или ежегодно.