Подход к версионированию межрелизного кода


#1

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

Вот пишу я библиотеку. Комичу чего-то там в нее. Потом решаю что настало время выпустить версию 3.0 - делаю в гите тег, меняю в Cargo.toml версию на 3.0.

Потом я продолжаю работать над библиотекой, комитя новые штуки. А версия в Cargo.toml так и остается 3.0, даже если я внес уже кучу несовместимых изменений. И только вот в момент среза 4.0 я меняю версию.

Вроде, во всей раст экосистеме вижу что люди так работают, но это вот точно правильный подход все? Может надо после выпуска 3.0 в коде первым же комитом менять что это уже 4.0.0-alpha.0 или 4.0.0-draft.0 какой-нибудь?

Киньтесь мыслями-ссылками-ликбезами, пожалуйста.


#2

Хороший вопрос.
Мне кажется, это не только в Расте так работают.
Другого решения не видел, к сожалению.


#3

А почему ты решил, что ты должен сразу же менять на 4.0.0-alpha.0 или 4.0.0-draft.0? Может быть так, что сразу после релиза ты обнаружил багу внутри кода, которая не затрагивает API, тогда ты пушишь фикс, создаешь новый тег 3.0.1, и пушишь в крейтс 3.0.1


#4

Да, и правда. Ну тогда сразу после выпуска 3.0.0 надо хз вообще на что версию менять. В ветках работать отдельных? )


#5

Возможно работу над новой версией вести в отдельной ветке и от неё уже делать альфы/беты/rc, а в момент релиза - сливать с мастером, как предлагает git flow. В таком случае и семантическое версионирование будет соблюдаться, и код новой версии не будет смешан с кодом старой.


#6

Спасибо, пойду gitflow перечитаю как именно они этот вопрос предлагают решать.


#7

Зачем менять? Не забывай, что ты код пишешь в svc, а релизишь в крейтс. Конечному пользователю должно быть вообще пофигу на то, что у тебя внутри svc творится на текущий момент.

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

Хорошие примеры такого подхода: futures-preview 0.3.0-alpha.12

Антипримеры (релизнули без проверок): futures 0.1 -> 0.2 (в итоге отозвали версию) , nom 3 -> 4 (получилось непонятно что)


#8

Например, потому что я не использую crates.io, а пилю какую-то закрытую систему библиотек, которые живут в закрытых репах, составляя иерархию зависимостей.

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

Ага. Там выше вариант с ...-draft еще был, это уже по семантике ближе будет, но тоже хз.


#9

Тогда распиливай на master и develop.
Ветку для мержа PR делаешь develop, а релиз кода происходит через мерж develop в master + tag


#10

Из гиттера:

Kai Ren @tyranron:

Я понимаю это так:

  1. У нас есть релизнутая версия 3.0.0, коммит с тегов, все дела.
  2. Последующими коммитами (или PR’ами) версия бампается в заисимости от того, какие изменения несутся с точки зрения semver. Если patch, то на 3.0.1-dev, если тянет на ап minor version по semver, то бампается на 3.1.0-dev, и если ап major version, то 4.0.0-dev, соотвественно.
  3. Перед релизом делается релизный коммит, в котором приводится в порядок ченджлог, наводится остальной марафет, в том числе и в Cargo.toml с версии убирается приставка -dev. И вешается сверху Git tag соотвествующий. Сюда же могут идти и всякие alpha/beta как пре-релизы.

Минус только в том, что нужно думать о semver каждый раз, когда коммитишь в master. Но тоже, смотря с какой стороны на это смотреть, это может быть и плюс.


#11

Если нужно поддерживать некогда релизнутые версии патчами, лучше ветвить вместо тегов. Из очевидных недостатков - больше геморроя с черрипиками важных патчей.


#12

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


#13

#14

Вопрос в том как обрабатывает зависимости Cargo.

У Мавена для Явы есть понятие “SNAPSHOT”, роллин версия. Т.е. версия 1.0-SNAPSHOT она выше 0.9 и ниже 1.0


#15

Как вариант использовать tag и перемещать его при коммите.

[dependencies]
rand = { git = "https://github.com/user/crate", tag = "1.0-rolling" }

Ну а со стороны библиотеки делать

git tag -f "1.0-rolling"

git push --force origin 1.0-rolling