Или ссылку на гит репозиторий сделать для модуля, раз нужен последний коммит всегда

Потому что тогда он становится сильно связан с основными кодом

А как он слабо связан, если становится критичным покоммитное версионирование?

про критичность никто не говорил, но если надо наладить , например, AB-тестирование - может пригодится

Могу еще как-то понять если ссылки идут на свой же код в гитхабе, но полагаться на чужие репозитории? Мало ли чего владельцу в голову взбредет, вон регулярно такие истории из мира Go да JS слышу. Да даже в своих проектах иногда приходится тот же jitpack использовать, каждый раз не очень комфортно ссылаться на определенный коммит, мало ли чего там владелец наворотил, может он вообще не думал что это будет билдиться и это какой-то промежуточный коммит, в таком случае придется еще и конечному пользователю сидеть разбираться а что же пошло не так. Но даже так, считаю такое решение лучше (но все еще очень сомнительное) чем прямые ссылки на гитхаб, для системы сборки это хоть выглядит как что-то родное и не надо опасаться что еще и в модуле который тянет зависимости с гитхаба какие-то проблемы возникнут

тесты и коммит-SHA решают эти проблемы, из Go и JS прилетает в основном случаи связанные с использованием HEAD вместо конкретного коммита, в депсах такое не предусмотренно специально.

т.е. для библиотеки теперь тоже тесты гонять надо будет?

ну и что бы ложное впечатление не создавалось - я не за то что бы использовать гит ссылки везде и всюду, но за разнообразие интсрументов

для твоего кода который библиотеку использует

все еще надо быть уверенным что хттп хэндлер вернет тот документ который предполагалось и это не означает что разработчик тестирует библиотеку которая генерирует его

покоммитное версионирование is like:
-у нас либа устарела
-а какая у нас версия?
-0001ddfeb1fca2099d4483c4f1bfa4d3d2036d5c
-ааа, да, пора обновляться

с тегами получше будет конечно, но все равно

сначала стоит определить что такое “устарела”
у меня в проекте есть зависимость которой 8 лет - она устарела или нет?

так суть не в этом, суть в том, что эти вот кучи циферок тебе ничего не говорят о либе

еще как говорят - git checkout 0001ddfeb1fca2099d4483c4f1bfa4d3d2036d5c и смотрим в ридми или в код

и что ридми что код - будут в точности согласованны с тем что работает в моем проекте

очень удобно, да
не так удобно, как просто смотреть релизы и изменения в них, но всё равно очень удобно

согласен, не всем такой подход подойдет, но решается тулингом, например cljdocs можно развернуть локально и тригерить покоммитно

ну видимо придется хранить зависимости в SVN репо, что-бы совместить приятное с полезным :)

А можно в одном предложении, чем по коммитам лучше?