Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 58
Я бы сделал это как SPEC.YYYY.[MM * 10000 + GEN] - 10к пересборок врядли возможны за месяц, а если возможны - ну дорисовать еще нолик. Первый номер сидит в переменных гитлаба, и меняется ручками ооочень редко, остальное вычисляется на лету. При этом оно вполне информативно.
Требование "сделать новое приложение при значительных изменениях" - абсолютно нереалистично в энтерпрайзе, IMHO - и будет источником дикого оверхеда в репозиториях, пайплайнах, и проч...
Я бы предложил не усложнять себе жизнь без причины, и продолжать пользоваться либо SemVer, либо просто инкрементальными номерами билдов (это когда приложение уже который год 0.1.X, и X>200 :-)
А разработчикам объяснять смысл версионирования, а не правила. Ведь смысл версионирования в чем - если у нас на проде есть версия X.Y.Z, а нас просят откатить до A.B.C - то надо или внимательно читать changelog (или git diff), или:
Отличие только в последнем компоненте - откатывать можно без проблем, оно не упадет.
Отличие в средней цифре - смотреть changelog, ибо там может быть что-то необратимое (а-ля миграция в БД), а может быть - и нет. Протестировать новую конфигурацию надо бы, но скорее для собственного успокоения.
Отличие в major-версии - гарантированно сломается все вокруг. Если очень надо - то это целый проект с селективным даунгрейдом соседних сервисов и обязательным тщательным тестированием совместимости.
И, соответственно, разработчик должен в своей голове прокручивать эти сценарии, и решать что он поменял, и какую condensed-информацию он доносит изменением версии. Если не уверен - озвучивать на дейлике, и пусть команда решает...
IMHO - и будет источником дикого оверхеда в репозиториях, пайплайнах, и проч...
Прикинул насколько реалистично реализовать такое в нашей компании. Репозиторий создаётся одной кнопкой. Чтобы шаблонный пайплайн развернуть, нужно заполнить небольшой конфиг на пол экрана и файл стендозависимых параметров, за пол часа сделать можно.
Вот ресурсы для запуска выделить не так просто. Нужно как минимум обратиться к руководителю, чтобы сервер выделил на тесте и проме. Но несказать, что это невозможно, всё же несовместимые версии не часто выпускаются. Зато если к руководителю разарботчик 5 раз за год приходит, и говорит, что снова несовместимо поменял API, у руководителя возникнут вопросы к этому разработчику.
Самая сложная проблема в бюрократии: нужно подготовить арх документацию, согласовать всё с безами, выпустить сертификаты, роуты создать, проходы открыть. Вот это действительно проблема. 10 раз подумаешь, нужны ли тебе несовместимые изменеия.
Вообще я бы сказал, что в интерпрайзе несовместимые изменения - редкость. Сделать новое API не проблема, а вот заставить всех потребителей бросить продуктовые задачи и переписывать работающую интеграцию очень не просто.
Ведь смысл версионирования в чем - если у нас на проде есть версия X.Y.Z, а нас просят откатить до A.B.C - то надо или внимательно читать changelog (или git diff)
А часто вам приходилось откатываться на предыдущую мажорную версию?
У нас требуется все доработки закрывать тогглами. Поэтому если что-то ломается после релиза, сразу откатываемся на предыдущую версию и чиним, что поломали. Если что-то ломается после включения тоггла, то выключаем тоггл, и чиним новую доработку.
На мажорную - нет. Идея закрыть все фича-флагами - сама по себе прекрасна, и мы стараемся ее использовать, но:
Обернуть каждый чих в тоггл - безумно дорого. Если идти по этому пути - то любой багфикс, и вообще любое изменение кода - должно быть отменяемо снятием фича-флага (по крайней мере в следующих нескольких релизах). Это делает код менее понятным, это увеличивает сложность отладки (нужно воссоздавать не только проблемные данные, но и детали конфигурации), и т.д. Если подумать философски - то мы информацию об изменениях кода из темпоральной области (версии, даты, релизы) переносим в пространственную (раздувая размер поверхности кода). Принципиального выигрыша достигнуть тут нельзя - законы сохранения не позволят. В некоторых частных случаях, да - это удобно.
Существуют вещи, живущие помимо кода - например, схемы БД, внешние бизнес-правила, которые система тянет из репозитория, и т.д. Проблема в том, что вы их не контролируете (из кода, на мета-уровне - понятно что контролируете). Таким образом, тоггл в коде формально отменяет изменения, но при этом в бизнес-смысле система оказывается еще более сломана. Версии создают надежные отметки, по которым вы синхронизируете внутренние свойства компонента, и свойства внешних по отношению к нему объектов
Важно понимать, что помимо версионирования компонентов, в сложной системе существует версионирование релизов. Да, понятно что можно все компоненты собирать из монорепы, и тогда версия компонентов в целом равняется версии релиза - но такой экстрим я никогда вживую не видел. Обычно есть зоопарк сервисов, одни из которых меняются часто, другие - редко. И когда мы создаем и тестриуем сущность "релиз" - то есть собираем индивидуальные версии компонентов и конфигураций, тестируем, и потом выкатываем в продакшн - то несмотря на то что каждый компонент у нас SemVer, релиз может версионироваться по другим правилам. Например, в одном из проектов - мы начинали с собственных имен релизов по алфавиту: "Penquin, Quarrel, итд", а потом перешли на YYYY.release-no (2025.01, 2025.02...).
Опять-таки, я призываю думать о версионировании (да и о многом другом), не в терминах правил ("когда мне надо увеличить какой номер в релизе"), а в терминах целей: ("какую информацию я хочу предоставить увеличив номер в релизе"). Потому что если у команды нет понятной всем цели версионирования - то набор правил может быть произвольным, вплоть до кидания кубика...
Ну т.е. у вас получилось что-то типа убунтовской схемы?
Софтина "Баба Яга" 24.4, Софтина "Баба Яга" 25.4, Софтина "Горыныч" 25.9, Софтина "Кошей" 26.4 и т.д.?
MyApp 1.0
MyApp 1.1
MyApp 1.2
MyApp2 1.3
MyApp2 1.4
MyApp3 1.5
Т.е. мы просто MAJOR номер переносим в имя. А если имя делать совсем другое, то встретив два приложения вы не сможете понять что это одно и тоже приложение
Т.е. мы просто MAJOR номер переносим в имя
Так можно, но я бы это считал именно компромисным решением.
А если имя делать совсем другое, то встретив два приложения вы не сможете понять что это одно и тоже приложение
А это не одно и то же приложение. Да, они оба могут выполнять одну задачу, и одно может быть логическом продолжением другого, но приложения разные.
Я пока искал примеры переименований мажорных разного ПО, наткнулся где-то, что Hadoop MapReduce вместо выпуска следующей мажорной версии сделали отдельный проект Spark. Прям идеальный пример для статьи. Стал икать ему подтверждение, но не нашёл. Пришёл к выводу, что Spark делала независимо другая команда, но впечатлялась реализацией Hadoop MapReduce, решая при том проблемы Hadoop MapReduce.
В статью этот пример включать не стал, но вопрос филосовский, подходит он или нет. Вся разница - та же самая команда выпускает новую библиотеку, или другая похожую. Обе библиотеки решают одну и ту же проблему, обе используеются в одних и тех же кейсах, они разные, но зато обе можно одновременно использовать в одном приложении, и постепенно перейти с одной на другую. А при выпуске новой мажорной версии, вы не сможете реализовать постепенный переход, но рафакторинг может потребоваться не меньше, чем переход на другую бибилиотеку.
Да, они оба могут выполнять одну задачу, и одно может быть логическом продолжением другого, но приложения разные.
Так это и плохо, на мой взгляд. Не сразу понятно что программа B это развитие программы A
Ещё хуже, когда их становится три и больше. Пойми сразу, кто из приложений или библиотек более продвинутый - Баба Яга 26.1, Кощей 26.1 или Горыныч 26.1.
В macOS уже были всякие Sierra, Sonoma и El Capitan. Более-менее терпимо, когда они по алфавиту расположены, как Oreo и Nougat, но всё равно с такими списками имён неудобно работать в системах мониторинга и логирования. А когда мажорных названий станет больше 26 - то и в принципе везде станет неудобно их использовать, английских букв то всего 26.
Ну т.е. семвер не осилили, придумали свой велосипед?
То что у вас семвер скатился к 1.0.%buildnumber% не значит что в семвере проблема.
UPD: почитал статью Махмуда Хашеми по ссылке и это какой-то... мусор? Типа "смотрите, кто-то может не соблюдать семвер, поэтому семвер плохой".
Я не утверждаю, что SemVer плохой. Когда он появился, он решал проблемы, которые на тот момент существовали, когда все использовали GitFlow и нужно было решать проблемы с зависимостями.
Сейчас мы работаем по TBD. Количество установок в пром - одна из метрик, по которой моё руководство оценивает работу разработчиков, и чем выше тем лучше. В таких условиях приходится все процессы максимально автоматизировать, и вставлять в пайплайн ручную операцию по установки версии сборки неразумно.
Но а в то, что по SemVer невозможно автоматически расчитать версию - это факт, с которым нет смысла спорить.
SemVer для моих условий не подходит, но как и писал в статье, мои проблемы решаются с помощью CalVer. Но Махмуд Хашеми в своей статье приводит CalVer, как универсальное решение. Я не считаю CalVer универсальным решением. Он не подходит для библиотек и фреймворков. И попытался найти способ сделать более универсальную методологию.
почитал статью Махмуда Хашеми по ссылке и это какой-то... мусор
Для меня эта статья стала поводом задуматься. Автор решал проблемы, которые для него казались критичными. Я релаю проблемы, которые мне кажутся критичными
Версию используете для чего-то? Почему бы тогда просто id пайплайна не использовать или генерируемый растущий номер?
Потому что если версия используется кем-то кроме вас лично, то там семвер удобен. Если только вы сами - то что угодно делайте, пока сами понимаете что и зачем.
Велосипеды делать, когда кто-то кроме вас будет этим пользоваться - очень грустная история.
ПС: версии можно поднимать просто при мержах. Либо руками (разработчик ломает совместимость, поднимает версию), либо как то автоматизируя (https://gitversion.net/docs/reference/version-increments вот тут v3 позволяет делать это разработчику). Никто кроме разработчика не знает, сломал он совместимость или нет. И даже разработчику об этом думать надо, не знаю, может нынче какой-нибудь ИИ инструмент может помочь.
Но а в то, что по SemVer невозможно автоматически расчитать версию - это факт, с которым нет смысла спорить.
SemVer прекрасно рассчитывается автоматически на базе префиксов коммитов (feat!:, feat:, fix:, etc.).
А это уже культура разработки, которой может не быть, человеческий фактор, не проставил, или проставил не то, не та версия инкрементнулась. В этом плане календарное версионирование решает проблему.
В принципе какая разница что использовать если это используется и обосновано конкретно у вас в компании. Хоть A/B/C пишите вместо версии если вы 3 версии в год выпускаете, главное чтобы клиентам было понятно...
Или пишите четвертую цифробукву в семантическом/календарном версионирование, первые три стандартизированы и дальше хоть id пайплайна, хоть инкрементальный id сборки. Даже после прочтения статьи не очень понимаю какую именно проблему пытается решить автор. Чтобы все использовали новую улучшенную версию версионирования? А смысл?..
Вот у моего приложения одно версионирование, у приложения Яндекс Музыка другое, у JetBrains PyCharm третье, у Ubuntu четвертое. Я вижу что циферка пошла вверх, я понимаю что у меня устаревшая система. Какая вот мне разница это цифра билда или количество звезд на гитхабе в момент сборки...
А это уже культура разработки, которой может не быть, человеческий фактор, не проставил, или проставил не то, не та версия инкрементнулась.
Это решаемо. Например, утилита https://git-cliff.org/ позволяет вручную корректировать такие "плохие" описания коммитов. В ней это сделано для генерации ChangeLog из коммитов, но она и SemVer отлично вычисляет (и её удобно использовать для определения версии на CI).
В этом плане календарное версионирование решает проблему.
И CalVer и EvoVer - это просто альтернативные/красивые способы записи BuildID. Никакой проблемы помимо увеличения номера версии они не решают.
При этом ещё одна пересборка не требуется, достаточно переключить тоггл в конфигурации.
Тут единицей, подлежащей версионированию, должен быть набор собранного бинарника и включенных тогглов. Его версия меняется, когда тоггла переключают.
"Мы запустили систему версии X.Y+1.Z". А то что бинарник не поменялся - это уже особенности имплементации. Он подчиненный артефакт, составная часть приложения версии X.Y+1.Z
Что касается самого бинарника - я бы инкрементировал версию тогда, когда изменения становятся хоть кому-то видны(включая тестовые стенды).
А тоглы важны в этой схеме? Я по статье не понял, если честно.
Контракты апи нужно версионировать, но это должно быть сделано при билде. Добавили контракты, апнули версии. Сломали контракты - отметили факт в версии. Включен или выключен тогл, вроде как особенность внутренней реализации сервиса и на поведение (в том числе версии чего либо) влиять не должно.
А тоглы важны в этой схеме? Я по статье не понял, если честно.
Это же тоггл функционала. Пока не переключен - то ничего нового как бы и нет, хотя в бинарнике и присутствует. Т.е. видимая версия(системы, не бинарника) должна оставаться той же (ну или patch версию можно увеличить опять же у всей системы)
Тогглы в схеме не важны. Про тогглы написал лишь для примера, что не всегда очевидно, как по SemVer инкрементировать версию.
У семвера по моему вполне ясно описано, как инкрементировать. Если тоглы не важны, то зачем про них писать?
Тогглы в схеме не важны.
Это невозможно. Если они что-то меняют, то система с одними включенными тогглами - это не та же система, что с другими.
Это другая версия системы, с другими возможностями, несмотря на то что бинарные артефакты те же самые. И этот набор возможностей вполне можно (и очень желательно) версионировать.
В таком случае непонятно, что вы версионируете?
По мне, версия должна быть установленна при сборке артефакта, в CI. Состояние тогглов - это стендозависимые параметры.
В таком случае непонятно, что вы версионируете?
Весь сервис целиком. (Или, в другой терминологии - конфигурация системы)
Условно:
Service ver. 3.4.5
depends on:
binary ver.: 3.5.6
toggle set: 3.4.5
Когда тоггл перекидывается, ставится
Service ver. 3.5.1
depends on:
binary ver.: 3.5.6
toggle set: 3.5.1
И происходит сборка/деплой. Но не бинарника (он тот же самый остается), а всего сервиса.
установленна при сборке артефакта, в CI. Состояние тогглов - это стендозависимые параметры.
Состояние/конфигурация стенда - это тоже артефакт.
Если после переключения тогглов стенд начал что-то дополнительное уметь - значит, вот этот весь стенд должен добавить в минороной версии.
Если обратную совместимость при этом сломали (т.е. то/те, кто им пользуются, начали ломаться) - то должна повысится и можорная версия.
Понял, о чём вы. В вашей терминологии я подразумевал binary ver.
Состояние/конфигурация стенда - это тоже артефакт.
С этим соглашусь. Но мы тогглы рассматриваем не набором с текущим состоянием. У нас каждый тоггл живёт независимым от остальных жизненным циклом.
Подход, который вы предложили тоже может существовать. Но вам понадобилось 2 версии по semver, чтобы описать текущую версию запущенной системы. На мой вкус - это лишь подтверждает, что в данном примере использование semver не так очевидно.
Но вам понадобилось 2 версии по semver, чтобы описать текущую версию запущенной системы.
Версия, видимая наружу - одна. На нее потребители и смотрят. А то что там внутри - это версии компонентов и набор зависимостей, интересующая только разработчиков сервиса. Которые в любом случае целой кучей версий зависимостей оперируют.
Тогглы часто можно менять (включать и выключать) в рантайме. А/Б тесты так делают. Как вы предлагаете это версионировать?
Второй вопрос - что делать с комбинаторным взрывом? Количество вариантов состояния тогглов может быть очень большим.
Тогглы часто можно менять (включать и выключать) в рантайме. А/Б тесты так делают. Как вы предлагаете это версионировать?
Так и менять. Список тогглов - в неком файле под version control. Поменял, закоммитил, номер версии присвоил тегом, а оно автомагически рантайм меняет.
Для надежности/параноий можно еще и обратный процесс - когда рантайм опрашивается и результат кладется в ветку "как оно на самом деле сейчас есть". С последующим сравнением и воплями "сейчас на промышленном стенде не так как должно быть".
Второй вопрос - что делать с комбинаторным взрывом?
А что с ним? Нам же не надо в номере версии описывать, что там включено и все эти варианты. Нам нужна последовательная нумерация состояния стенда, так, чтобы те, кто им пользуется. поняли, обратно ли совместимо текущее состояние с тем, что они последний раз видели и к которому готовились.
Вы не совсем правильно понимаете SemVer. SemVer нужен для публичных библиотек, чтобы их пользователи могли понять, когда обновляться относительно безопасно. Если вы делаете конечный продукт, который не входит в состав более крупного, он может следовать любой схеме версий
Если вы делаете конечный продукт, который не входит в состав более крупного, он может следовать любой схеме версий
Ну почему... Это как трактовать.
В конечном продукте версии 14.17.36 пользователи смогут работать так же успешно (и искать инструкции в своих Wiki) как с продуктом версии 14.16.1 (увеличилась минорная версия, т.е. где-то какие-то дополнительные менюшки появились, которые ничему не мешают, пока в них не лезешь)
А вот продукту версии 15.1.1 уже придется обучаться заново, потому что весь API/UI пользователя поломали и переделали.
Не совсем так. SemVer оперирует понятием "совместимое изменение". И это ключевой фактор: чтобы определить является ли изменение совместимым нужно иметь возможность как-то эту совместимость оценивать. Если продукт это библиотека, то способ оценить совместимость очевиден: по API. Но если продукт это CLI/GUI приложение, то понятие совместимость становится крайне туманным. Например для CLI можно считать совместимостью формат аргументов/флагов, но является ли совместимым изменением незначительное отличие в формате выводимых данных - уже не так очевидно.
Ещё один ключевой момент SemVer, который упустил автор статьи - задача SemVer коммуницировать ключевую информацию чтобы пользователь мог определиться нужно ли ему (полезность) и когда лучше (сложность) обновляться. Это полезно только в ситуации, когда время обновления выбирается пользователем. Что, очевидно, не так для микросервисов и для веб-фронта - и то и другое обновляется централизованно компанией, а не вразнобой пользователями.
При отсутствии любого из этих двух факторов пропадает смысл использовать SemVer.
Ещё один ключевой момент SemVer, который упустил автор статьи - задача SemVer коммуницировать ключевую информацию чтобы пользователь мог определиться нужно ли ему (полезность) и когда лучше (сложность) обновляться
Эту проблему я упоминал, но не со стороны пользователя конечного приложения. Для пользователя действительно может быть не так важен переход на следующую мажорную версию.
Я рассматривал пример, когда вы потребитель библиотеки, которая выпускает новую мажорную версию. В таком случае у вас не такой свободный выбор. После выпуска новой мажорной версии библиотеки предыдущая ветвь развиваться не будет. В такой ситуации разработчик вынужден переходить, даже если нет в этом необходимости, либо копить техдолг.
В таком случае у вас не такой свободный выбор.
Вполне свободный: обновиться сейчас или позднее, отказаться от обновления, перейти на другую библиотеку…
После выпуска новой мажорной версии библиотеки предыдущая ветвь развиваться не будет.
Зависит от библиотеки, некоторые продолжают поддерживать багфиксами предыдущий мажорный релиз ещё какое-то время. Особенно если по объективным причинам многие пользователи не хотят обновляться на последний мажор.
В такой ситуации разработчик вынужден переходить, даже если нет в этом необходимости, либо копить техдолг.
Отказ от перехода на новый мажор - это не всегда техдолг.
Но в общем и целом - всё это незначительные мелочи. Важно то, что SemVer даёт ключевую информацию необходимую для принятия таких решений, а другие схемы - не дают.
На мой взгляд, проблема при использовании semVer заключается в том, что для многих продуктов смена мажора это юридически-маркетингово-сертификационная штука и она не связана с какими-то несовместимыми изменениями. Т.е. мажор скорее используется, как эпоха. За ней должен идти мажор (который про совместимость) далее с минор (про фичи) и патч (про исправления).
Например 2026.2.7.4
В 2026-м году выпущено два несовместимых обновления, для последнего выпущено семь фича-релизов, для последнего выпущено четыре фикса.
Проблему нежелания заказчика обновляться, а получать обновления патчами (как следствие необходимость поддерживать N старых релизов) ни один способ версионирования не решит, т.к. это из другой плоскости.
для многих продуктов смена мажора это юридически-маркетингово-сертификационная штука и она не связана с какими-то несовместимыми изменениями
Эта проблема упоминается в статье, на которую я сослался https://sedimental.org/designing_a_version.html#case-study-chrome-vs-firefox . Поэтому не стал заострять на этом внимание
в статье не увидел примеров версионирования по EvoVer
Совместимость или не совместимость может определяться набором тестов. Если вы понаписали кода и теперь тесты не проходят - делаете новые версии тестов и обновляете мажор. Вроде бы так, не?
Можете воспринимать EvoVer, как CalVer 2.0.0
Как CalVer 2026.01, извините :)
Интересно как Astra свой Ver называет, когда меняется минор, а это оказывается мажорный релиз.
мне вот нравится ещё verrless (version less )
Полностью отказываемся от версий, всегда актуальное состояние
Вместо конфликтов- энтропия ( новый модуль условно был packet1 добавили packet2 который под капотом на 90% использует packet1 )
Поподробнее вот тут небольшая статья
На Go все писали без поддержки версий пакетов примерно 9 лет (до 2018). В целом, как ни странно, это было не так страшно, как выглядит на первый взгляд. Изредка использовали вендоринг, но большинство проектов и библиотек нормально жило без управления версиями - достаточно поддерживать стабильную работу в ветке master и избегать (по возможности) несовместимых изменений. Это доказывает, что без версий - жить можно. Но как только в 2018 появилась встроенная поддержка версионирования - все тут же начали её использовать. Это доказывает, что с версиями - жить лучше. ;-)
Но это не был version less
Так пакеты не всегда имели последнее состояние и не обновлялись сами. Например при билде
Спор про версионирование vs безверсионность, связан со спором о том, что лучше: квалифицированный дорогой разраб, которого сложно найти или куча низкоквалицифированных, дешевых и легкодоступных разрабов и тестеровщиков. Решение зависит от возможностей бизнеса приспособиться к тому или иному способу управления.
Мне кажется, не доказывает что "лучше". Для больших компаний более применимо скорее
Так пакеты не всегда имели последнее состояние и не обновлялись сами. Например при билде
Если не учитывать использование локального кеша - то всегда. Локально у разработчиков кеш обычно присутствовал, но вот на CI - наоборот. А поскольку сборка на CI обычно важнее - именно её результат релизится - то вполне корректно считать это version less, разве нет?
Мне кажется, не доказывает что "лучше". Для больших компаний более применимо скорее
На версионирование перешли абсолютно все, не только большие компании, но и индивидуальные разработчики опенсорса, которых никто не принуждал. Так что, как по мне, это вполне доказывает.
По первому, да считается, но очевидно тут есть проблема. Через час после всех тестов в ci получить ошибку типов при билде очень больно, не удивительно что стали фиксировать
По второму поводу, не все перешли, и это всё равно ничего не доказывает
Это логическая ошибка
В большинстве случаев так проще и эффективнее экономически
Но в результате мы получаем Легаси, то есть откладываем последствия и накапливаем ошибки
Хороших реализаций version less довольно мало, единственное где я увидел развитие этих идей это в $mol
Через час после всех тестов в ci получить ошибку типов при билде очень больно
Больно, да. Но все гошники дофига лет с этим жили, и, в целом, были довольны своим ЯП. Ну т.е. больно, но не так чтобы очень. Где это было неприемлемо - вендорили.
не все перешли
Честно, не знаю таких примеров. Есть устаревшие, не поддерживаемые проекты, которые никто не обновлял - это да. А вот актуальные, поддерживаемые, и продолжающие жить в GOPATH без версий - я не сталкивался. Наверное, пару исключений найдётся, если специально искать, но на фоне общего количества проектов на го - это погрешность, а не статистика.
и это всё равно ничего не доказывает
Почему не доказывает? Как по мне - это идеальное доказательство. Потому что у людей не просто был свободный выбор между несколькими вариантами (без версий, вендоринг, с версиями), но ещё и за много лет сформировавшаяся привычка жить без версий. Если в этой ситуации все дружно переходят на версионирование - это очень громкое и вполне однозначное заявление, как по мне.
Но в результате мы получаем Легаси, то есть откладываем последствия и накапливаем ошибки
По-моему общий консенсус в том, что лучше так, чем получать внезапные отличия в поведении просто из-за пересборки старой версии на CI через неделю после предыдущей, либо вообще сломанную сборку. Недостатки есть у всех подходов, но подход позволяющий обеспечить повторяемость сборки определённо выигрывает.
То что все перешли на такую систему не является аргументом само по себе, это аппеляция к большинству, например, в прошлом почти все верили в то что земля плоская.
Я согласен с вашими аргументами, что нужна повторяемость сборки
Version less может это обеспечить непрерывным обновлением ( при каждом запуске кода и тестов, например) а не ручным, как было в go до модулей
При длительном отсутствии измений конечно следующий билд скорее всего упадёт и нам придется привести систему в актуальное состояние
Спор про версионирование vs безверсионность, связан со спором о том, что лучше: квалифицированный дорогой разраб, которого сложно найти или куча низкоквалицифированных, дешевых и легкодоступных разрабов и тестеровщиков. Решение зависит от возможностей бизнеса приспособиться к тому или иному способу управления
Итого : для version less нужны дополнительные механизмы,такие как, автоматическое подтягивание зависимостей и проверка того что код не сломался ( билд проекта автоматически )
Если это ручным трудом оставить то будут возникать постоянно ошибки о которых мы говорим и всем захочется зафиксировать версии
Совместимость изменений проверяется тестированием, если после изменений энд ту энд тесты не надо переписывать значит изменения совместимые.
Энд ту энд тесты могут быть на на апи, на модуль (библиотеку), на аргументы командной строки. В общем тесты от входа до выхода, если старые тесты не падают на новой версии, то изменения совместимы. Если для полноценного тестирования надо дописать тесты то это минорные изменения. Если ни чего не поменялось то это патч изменения.
С sem ver нет ни каких проблем, если разработчики понимают что и для чего они делают. А если разработчики не владеют кодовой бащой и продуктом, то наверное это надо исправлять, а не придумывать недостатки SemVer.
Тесты проверяют на наличие любых изменений - а в новой версии изменения есть по определению, так что падение части тестов это норма. На совместимость должны проверять совершенно отдельные тесты, заточенные под это специально - что потребует, для начала, определить само понятие "совместимость" для конкретного продукта, а потом ещё и научиться его надёжно тестировать. На данный момент такого типа тесты если и встречаются, то это большая редкость.
Обычно "совместимость" контролируется либо формальными инструментами (которые проверяют только техническую совместимость API библиотеки или .proto-файла но не семантику/поведение этого API) либо вообще вручную (напр. для REST/OpenAPI мне такие линтеры как для proto пока не встречались). Тесты на семантику API написанные именно с целью контроля совместимости попадались редко и не были выделены в отдельную группу тестов совместимости, а были размазаны среди прочих (т.е. было крайне сложно понять что тестируется в этом плане, а что нет).
Версия должна строго вычисляться алгоритмически
Это невозможно. В том числе, и в вашем варианте:
sirius 26.01.0
altair 26.01.0
Какой алгоритм принимает решение поменять сириус на альтаир? Что отражает это изменение, если, судя по номеру, это вообще одна и та же сборка?
SemVer в своей полной версии перекрывает все потребности версионирования. А решение о присвоении номера версии должно приниматься на этапе сборки. У меня, например, сборка запускается по добавлению определённого тега к ветке: release-x.x.x. Или release-x.x.x-RCx. Какой функционал включён, ломает ли этот релиз совместимость – на момент сборки известно, и проставить корректный номер никакого труда не составляет. А программисты при коммитах используют номера тикетов, о том, в какую версию их коммит войдёт, им задумываться не нужно – зато в тикетах автоматически появляются ссылки на все связанные с ними коммиты.
Кроме того, есть ситуации, в которых ваш подход в принципе не работает. Например, при деплое в App Store можно передать только версию в формате х.х.х и номер билда, всё.
Создание нового репо при смене версии выглядит не менее странно. Опять же, я могу пометить текущее состояние любым тегом и потом хоть какие изменения делать – это не помешает мне при необходимости вернуться в данной версии. Такое ощущение, что у вас не очень умеют готовить гит, простите уж.
у меня не большой опыт, но вижу проблему с эво - тут же чистый маркетинг. потрясающий способ внушить потребителю, что у его копия приложения уже устарела, без аргументации в чем именно.
мне пришлось порядком покопаться в легаси, при отсутствии нормального описания зависимостей пактов. четкий semver давал хоть какую-то надежду, что libA:1.4.26b4 о которой нигде не сохранилось какое либо описание функциональности, но которая мне нужна из-за ряда других зависимостей хоть как-то похожа по поведению на libA:1.4.30, для которой есть документация и changelog.
и я понятия не имею сколько бы я еще часов угрохал (в т.ч. с иишкой), если бы мне потребалось проводить серию обновлений среди пакетов, версия которых именовалась поэтичными названиями с датами релиза
Версия должна быть числом
Необязательно. Более того, мажорные версии разного ПО с масштабными изменениями очень часто бывают не числом, а словом, например, Vista. Да и в более типичной ситуации бывает версионирование типа 15.b.3
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эволюция методологий версионирования