Существует два варианта перехода на версию 2: ветви и подкаталоги. Вы можете прочитать больше о них (с лучшими иллюстрациями) на https://research.swtch.com/vgo-module.
Эти две опции позволяют одной версии зависеть от другой. Например, когда вы реализуете версию 2, вы можете обновить версию 1, чтобы она зависела от версии 2 (но сохранить тот же API v1). Тогда вам нужно иметь только одну реализацию логики для вашей библиотеки. Это может или не может хорошо работать для вас, в зависимости от типа проекта, поддержки, которую вы хотите предоставить, и необходимых исправлений.
Филиалы
master: A -> B (v1.0.0) -> D (v1.0.1)
\
v2: -> C (v2.0.0)
В этом сценарии:
- Вы запускаете свой проект в ветке
master,
- Сделать несколько коммитов (
A и B),
- Tag
v1.0.0.
- Вы решили сделать решающее изменение. Итак, вы создаете новую ветку (
git checkout -b v2) и вносите в нее критические изменения. Теперь ваш go.mod должен быть обновлен, чтобы имя модуля заканчивалось на /v2 (по сути это новый модуль!).
- Вы решаете исправить ошибку в
v1, поэтому вы возвращаетесь в эту ветку, делаете новый коммит и отмечаете новую v1 версию.
Когда пользователю требуется определенная версия вашего модуля, go будет искать в двух ветвях, для которых одна предоставляет нужный модуль.
Подкаталоги
Что, если вы не хотите развиваться на ветках? Вы можете создать подкаталог для каждой основной версии. Версия 1 остается на верхнем уровне, затем новые версии перемещаются в подкаталоги:
go.mod (module example.com/foo)
foo.go
v2/
go.mod (module example.com/foo/v2)
foo.go
Когда вы помечаете этот репозиторий новыми версиями, v1 будет использовать версию верхнего уровня. Теги v2 будут использовать подкаталог v2.