У меня тут глуповатый вопрос в голове застрял, я хз даже как его толком загуглить.
Вот пишу я библиотеку. Комичу чего-то там в нее. Потом решаю что настало время выпустить версию 3.0 - делаю в гите тег, меняю в Cargo.toml версию на 3.0.
Потом я продолжаю работать над библиотекой, комитя новые штуки. А версия в Cargo.toml так и остается 3.0, даже если я внес уже кучу несовместимых изменений. И только вот в момент среза 4.0 я меняю версию.
Вроде, во всей раст экосистеме вижу что люди так работают, но это вот точно правильный подход все? Может надо после выпуска 3.0 в коде первым же комитом менять что это уже 4.0.0-alpha.0 или 4.0.0-draft.0 какой-нибудь?
А почему ты решил, что ты должен сразу же менять на 4.0.0-alpha.0 или 4.0.0-draft.0? Может быть так, что сразу после релиза ты обнаружил багу внутри кода, которая не затрагивает API, тогда ты пушишь фикс, создаешь новый тег 3.0.1, и пушишь в крейтс 3.0.1
Возможно работу над новой версией вести в отдельной ветке и от неё уже делать альфы/беты/rc, а в момент релиза - сливать с мастером, как предлагает git flow. В таком случае и семантическое версионирование будет соблюдаться, и код новой версии не будет смешан с кодом старой.
Зачем менять? Не забывай, что ты код пишешь в svc, а релизишь в крейтс. Конечному пользователю должно быть вообще пофигу на то, что у тебя внутри svc творится на текущий момент.
Альфы используют тогда, когда есть некий код, похожий на рабочий, но надо проверить, рабочий он или нет. Тогда выпускают альфу, просят пользователей протестировать, а потом уже релизят окончательную версию.
Например, потому что я не использую crates.io, а пилю какую-то закрытую систему библиотек, которые живут в закрытых репах, составляя иерархию зависимостей.
В целом оно все функциональных неудобств не так что бы много/часто создает, просто пытаюсь понять как филосовски/идиологически можно синхронизировать захардкоженную в код версию и гибкую/ветвящуюся сущность VCS. Странно это как-то, что в коде написано 3.0, а он уже ни разу не 3.0. Но, может, не нужно и пытаться вообще таким заниматься, а то бюрократией захлестнет.
Ага. Там выше вариант с ...-draft еще был, это уже по семантике ближе будет, но тоже хз.
У нас есть релизнутая версия 3.0.0, коммит с тегов, все дела.
Последующими коммитами (или PR’ами) версия бампается в заисимости от того, какие изменения несутся с точки зрения semver. Если patch, то на 3.0.1-dev, если тянет на ап minor version по semver, то бампается на 3.1.0-dev, и если ап major version, то 4.0.0-dev, соотвественно.
Перед релизом делается релизный коммит, в котором приводится в порядок ченджлог, наводится остальной марафет, в том числе и в Cargo.toml с версии убирается приставка -dev. И вешается сверху Git tag соотвествующий. Сюда же могут идти и всякие alpha/beta как пре-релизы.
Минус только в том, что нужно думать о semver каждый раз, когда коммитишь в master. Но тоже, смотря с какой стороны на это смотреть, это может быть и плюс.
Если нужно поддерживать некогда релизнутые версии патчами, лучше ветвить вместо тегов. Из очевидных недостатков - больше геморроя с черрипиками важных патчей.