Использовать SVN / GIT для истории версий программного обеспечения? Или что-то другое?

По моему опыту, сообщения о коммитах обычно содержат технически подробные сведения о внесенных изменениях. Обычно они не подходят для заметок о выпуске. Для этого я держу более дружественный документ с заметками о выпуске. Я надеюсь перейти к веб-системе, такой как Redmine, которая может отслеживать улучшения и ошибки.

Если сообщения о фиксации хороши (то есть не технически), есть способы извлечь эту информацию из репозитория. Например, вот команда, которую я использовал для извлечения сообщений из SVN:

svn log --verbose https://<address to server>/<repo name>/ > svnMessages.txt 

Я использую журнал изменений, чтобы сообщить об ошибках, изменениях или новых функциях конечным пользователям. Я моделирую свой журнал изменений на tortoisesvn, который использует BUG: CHG: NEW :.

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

Когда я освобождаюсь, я могу легко вытащить все последние строки журнала изменений и обновить журнал изменений / веб-сайт / и т.д. С помощью префиксов в любой строке журнала изменений в истории коммитов я также могу автоматизировать это.

Мне нравится, как этот метод объединяет два потока информации в хранилище, где они должны быть.

Вы можете использовать git у себя дома, а затем просто сделать вырезки из репозитория для основных версий (тарболы).

Я бы выбрал систему контроля версий, которую предпочитает ваша команда разработчиков (склоняясь к git, если они апатичны!). То, что вы хотите, - это стандартный метод «публикации» основной версии вместе с журналом изменений. Это можно сделать с помощью скрипта, который загружает из репозитория и отображает журнал изменений, через веб-систему, это может быть просто общий каталог в локальной сети, FTP-сайт и т. Д. И т. Д. И т. Д.

Ваш вопрос:

Бизнес на самом деле не хочет проходить траление нашего репозитория SVN, не так ли? Мне было интересно, если кто-то знал о лучшем способе сделать это? Какие-либо предложения?

Дополнительная информация, которую вы предоставили:

Не-разработчик, может быть, член Business из-за пределов IT, хотел бы знать об изменениях, которые произошли в последнем выпуске, исправлениях ошибок и т. Д. Поэтому вы не хотите хранить там историю версий для всего бизнеса, но, возможно, в отдельном месте. система

Отдельная система: Microsoft Exchange

Решение: напишите им, когда выйдет новый релиз.

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

Многие пользователи, особенно плательщик счетов при удаленной работе, ценят ежедневные обновления.