Вы должны выполнить обновление основной версии, если изменения, которые вы вносите в потенциальную новую версию, не могут гарантировать обратную совместимость для пользователей модуля. Например, вы внесете такое изменение, если измените общедоступный API вашего модуля так, чтобы он нарушал работу клиентского кода, использующего предыдущие версии модуля.
Примечание. Каждый тип релиза - основной, минорный, патч (релиз исправлений) или предварительный релиз - имеет разное значение для пользователей модуля. Эти пользователи полагаются на эти различия, чтобы понять уровень риска, который релиз представляет для их собственного кода. Другими словами, при подготовке релиза убедитесь, что номер его версии точно отражает характер изменений с момента предыдущего релиза.
Рекомендации по обновлению основной версии
Вы должны обновляться до новой основной версии только тогда, когда это абсолютно необходимо. Обновление основной версии означает значительный переворот как для вас, так и для пользователей вашего модуля. Когда вы думаете об обновлении основной версии, подумайте о следующем:
- Сообщите своим пользователям, что выпуск новой основной версии означает для вас поддержку предыдущих основных версий.
- Предыдущие версии устарели? Поддерживаются как раньше? Будете ли вы поддерживать предыдущие версии, в том числе с исправлениями ошибок?
- Будьте готовы взять на себя обслуживание двух версий: старой и новой. Например, если вы исправляете ошибки в одной, вы часто будете переносить эти исправления в другой.
- Помните, что новая основная версия - это новый модуль с точки зрения управления зависимостями. Вашим пользователям необходимо будет выполнить обновление, чтобы использовать новый модуль после выпуска, а не просто выполнить обновление.
Это потому, что в новой основной версии путь к модулю отличается от пути к предыдущей основной версии. Например, для модуля, чей путь к модулю - example.com/mymodule, версия v2 будет иметь путь к модулю example.com/mymodule/v2. - При разработке новой основной версии вы также должны обновить пути импорта везде, где код импортирует пакеты из нового модуля. Пользователи вашего модуля также должны обновить свои пути импорта, если они хотят перейти на новую основную версию.
Разветвление для основного релиза
Самый простой подход к работе с исходным кодом при подготовке к разработке новой основной версии - это разветвление репозитория на последней версии предыдущей основной версии.
Например, в командной строке вы можете перейти в корневой каталог вашего модуля, а затем создать там новую ветку v2.
$ cd mymodule
$ git checkout -b v2
Switched to a new branch "v2"
Схема, показывающая репозиторий, ответвленный от master к v2:
После разветвления исходного кода вам необходимо внести следующие изменения в исходные файлы для вашей новой версии:
- В файле go.mod новой версии добавьте номер новой основной версии к пути к модулю, как в следующем примере:
- Существующая версия: example.com/mymodule
- Новая версия: example.com/mymodule/v2
- В коде Go обновите каждый импортированный путь к пакету, в который вы импортируете пакет из модуля, добавив номер основной версии к части пути к модулю.
- Старый оператор импорта: import "example.com/mymodule/package1"
- Новый оператор импорта: import "example.com/mymodule/v2/package1"
Читайте также:
- Создание модуля в Golang
- Управление зависимостями в Golang
- Разработка и публикация модулей в Golang
- Выпуск модуля и рабочий процесс управления версиями
- Управление исходным кодом модуля
Комментариев нет:
Отправить комментарий