Несовместимость можно обнаружить тестами, но всё же при поломке тестов нужно не мажорную версию поднимать, а смотреть, всё ли мы правильно реализовали.
Роль тестов - проверить реализацию, а не определять версию сборки.
Ещё один ключевой момент SemVer, который упустил автор статьи - задача SemVer коммуницировать ключевую информацию чтобы пользователь мог определиться нужно ли ему (полезность) и когда лучше (сложность) обновляться
Эту проблему я упоминал, но не со стороны пользователя конечного приложения. Для пользователя действительно может быть не так важен переход на следующую мажорную версию.
Я рассматривал пример, когда вы потребитель библиотеки, которая выпускает новую мажорную версию. В таком случае у вас не такой свободный выбор. После выпуска новой мажорной версии библиотеки предыдущая ветвь развиваться не будет. В такой ситуации разработчик вынужден переходить, даже если нет в этом необходимости, либо копить техдолг.
Понял, о чём вы. В вашей терминологии я подразумевал binary ver.
Состояние/конфигурация стенда - это тоже артефакт.
С этим соглашусь. Но мы тогглы рассматриваем не набором с текущим состоянием. У нас каждый тоггл живёт независимым от остальных жизненным циклом.
Подход, который вы предложили тоже может существовать. Но вам понадобилось 2 версии по semver, чтобы описать текущую версию запущенной системы. На мой вкус - это лишь подтверждает, что в данном примере использование semver не так очевидно.
Я не утверждаю, что SemVer плохой. Когда он появился, он решал проблемы, которые на тот момент существовали, когда все использовали GitFlow и нужно было решать проблемы с зависимостями.
Сейчас мы работаем по TBD. Количество установок в пром - одна из метрик, по которой моё руководство оценивает работу разработчиков, и чем выше тем лучше. В таких условиях приходится все процессы максимально автоматизировать, и вставлять в пайплайн ручную операцию по установки версии сборки неразумно.
Но а в то, что по SemVer невозможно автоматически расчитать версию - это факт, с которым нет смысла спорить.
SemVer для моих условий не подходит, но как и писал в статье, мои проблемы решаются с помощью CalVer. Но Махмуд Хашеми в своей статье приводит CalVer, как универсальное решение. Я не считаю CalVer универсальным решением. Он не подходит для библиотек и фреймворков. И попытался найти способ сделать более универсальную методологию.
почитал статью Махмуда Хашеми по ссылке и это какой-то... мусор
Для меня эта статья стала поводом задуматься. Автор решал проблемы, которые для него казались критичными. Я релаю проблемы, которые мне кажутся критичными
Так можно, но я бы это считал именно компромисным решением.
А если имя делать совсем другое, то встретив два приложения вы не сможете понять что это одно и тоже приложение
А это не одно и то же приложение. Да, они оба могут выполнять одну задачу, и одно может быть логическом продолжением другого, но приложения разные.
Я пока искал примеры переименований мажорных разного ПО, наткнулся где-то, что Hadoop MapReduce вместо выпуска следующей мажорной версии сделали отдельный проект Spark. Прям идеальный пример для статьи. Стал икать ему подтверждение, но не нашёл. Пришёл к выводу, что Spark делала независимо другая команда, но впечатлялась реализацией Hadoop MapReduce, решая при том проблемы Hadoop MapReduce.
В статью этот пример включать не стал, но вопрос филосовский, подходит он или нет. Вся разница - та же самая команда выпускает новую библиотеку, или другая похожую. Обе библиотеки решают одну и ту же проблему, обе используеются в одних и тех же кейсах, они разные, но зато обе можно одновременно использовать в одном приложении, и постепенно перейти с одной на другую. А при выпуске новой мажорной версии, вы не сможете реализовать постепенный переход, но рафакторинг может потребоваться не меньше, чем переход на другую бибилиотеку.
Ведь смысл версионирования в чем - если у нас на проде есть версия X.Y.Z, а нас просят откатить до A.B.C - то надо или внимательно читать changelog (или git diff)
А часто вам приходилось откатываться на предыдущую мажорную версию?
У нас требуется все доработки закрывать тогглами. Поэтому если что-то ломается после релиза, сразу откатываемся на предыдущую версию и чиним, что поломали. Если что-то ломается после включения тоггла, то выключаем тоггл, и чиним новую доработку.
IMHO - и будет источником дикого оверхеда в репозиториях, пайплайнах, и проч...
Прикинул насколько реалистично реализовать такое в нашей компании. Репозиторий создаётся одной кнопкой. Чтобы шаблонный пайплайн развернуть, нужно заполнить небольшой конфиг на пол экрана и файл стендозависимых параметров, за пол часа сделать можно.
Вот ресурсы для запуска выделить не так просто. Нужно как минимум обратиться к руководителю, чтобы сервер выделил на тесте и проме. Но несказать, что это невозможно, всё же несовместимые версии не часто выпускаются. Зато если к руководителю разарботчик 5 раз за год приходит, и говорит, что снова несовместимо поменял API, у руководителя возникнут вопросы к этому разработчику.
Самая сложная проблема в бюрократии: нужно подготовить арх документацию, согласовать всё с безами, выпустить сертификаты, роуты создать, проходы открыть. Вот это действительно проблема. 10 раз подумаешь, нужны ли тебе несовместимые изменеия.
Вообще я бы сказал, что в интерпрайзе несовместимые изменения - редкость. Сделать новое API не проблема, а вот заставить всех потребителей бросить продуктовые задачи и переписывать работающую интеграцию очень не просто.
Добавил пример, сразу после описания схемы EvoVer
Несовместимость можно обнаружить тестами, но всё же при поломке тестов нужно не мажорную версию поднимать, а смотреть, всё ли мы правильно реализовали.
Роль тестов - проверить реализацию, а не определять версию сборки.
Эта проблема упоминается в статье, на которую я сослался https://sedimental.org/designing_a_version.html#case-study-chrome-vs-firefox . Поэтому не стал заострять на этом внимание
Эту проблему я упоминал, но не со стороны пользователя конечного приложения. Для пользователя действительно может быть не так важен переход на следующую мажорную версию.
Я рассматривал пример, когда вы потребитель библиотеки, которая выпускает новую мажорную версию. В таком случае у вас не такой свободный выбор. После выпуска новой мажорной версии библиотеки предыдущая ветвь развиваться не будет. В такой ситуации разработчик вынужден переходить, даже если нет в этом необходимости, либо копить техдолг.
Команду ls можно запустить с разными ключами и получить от этого разное поведение. Но это не значит, что вы запускаете разную версию команды.
Понял, о чём вы. В вашей терминологии я подразумевал binary ver.
С этим соглашусь. Но мы тогглы рассматриваем не набором с текущим состоянием. У нас каждый тоггл живёт независимым от остальных жизненным циклом.
Подход, который вы предложили тоже может существовать. Но вам понадобилось 2 версии по semver, чтобы описать текущую версию запущенной системы. На мой вкус - это лишь подтверждает, что в данном примере использование semver не так очевидно.
Тогглы в схеме не важны. Про тогглы написал лишь для примера, что не всегда очевидно, как по SemVer инкрементировать версию.
В таком случае непонятно, что вы версионируете?
По мне, версия должна быть установленна при сборке артефакта, в CI. Состояние тогглов - это стендозависимые параметры.
Я не утверждаю, что SemVer плохой. Когда он появился, он решал проблемы, которые на тот момент существовали, когда все использовали GitFlow и нужно было решать проблемы с зависимостями.
Сейчас мы работаем по TBD. Количество установок в пром - одна из метрик, по которой моё руководство оценивает работу разработчиков, и чем выше тем лучше. В таких условиях приходится все процессы максимально автоматизировать, и вставлять в пайплайн ручную операцию по установки версии сборки неразумно.
Но а в то, что по SemVer невозможно автоматически расчитать версию - это факт, с которым нет смысла спорить.
SemVer для моих условий не подходит, но как и писал в статье, мои проблемы решаются с помощью CalVer. Но Махмуд Хашеми в своей статье приводит CalVer, как универсальное решение. Я не считаю CalVer универсальным решением. Он не подходит для библиотек и фреймворков. И попытался найти способ сделать более универсальную методологию.
Для меня эта статья стала поводом задуматься. Автор решал проблемы, которые для него казались критичными. Я релаю проблемы, которые мне кажутся критичными
Так можно, но я бы это считал именно компромисным решением.
А это не одно и то же приложение. Да, они оба могут выполнять одну задачу, и одно может быть логическом продолжением другого, но приложения разные.
Я пока искал примеры переименований мажорных разного ПО, наткнулся где-то, что Hadoop MapReduce вместо выпуска следующей мажорной версии сделали отдельный проект Spark. Прям идеальный пример для статьи. Стал икать ему подтверждение, но не нашёл. Пришёл к выводу, что Spark делала независимо другая команда, но впечатлялась реализацией Hadoop MapReduce, решая при том проблемы Hadoop MapReduce.
В статью этот пример включать не стал, но вопрос филосовский, подходит он или нет. Вся разница - та же самая команда выпускает новую библиотеку, или другая похожую. Обе библиотеки решают одну и ту же проблему, обе используеются в одних и тех же кейсах, они разные, но зато обе можно одновременно использовать в одном приложении, и постепенно перейти с одной на другую. А при выпуске новой мажорной версии, вы не сможете реализовать постепенный переход, но рафакторинг может потребоваться не меньше, чем переход на другую бибилиотеку.
Да, главное чтобы в зависимостях название изменилось при несовместимом изменении, и можно было постепенно провести переход
А часто вам приходилось откатываться на предыдущую мажорную версию?
У нас требуется все доработки закрывать тогглами. Поэтому если что-то ломается после релиза, сразу откатываемся на предыдущую версию и чиним, что поломали. Если что-то ломается после включения тоггла, то выключаем тоггл, и чиним новую доработку.
Прикинул насколько реалистично реализовать такое в нашей компании. Репозиторий создаётся одной кнопкой. Чтобы шаблонный пайплайн развернуть, нужно заполнить небольшой конфиг на пол экрана и файл стендозависимых параметров, за пол часа сделать можно.
Вот ресурсы для запуска выделить не так просто. Нужно как минимум обратиться к руководителю, чтобы сервер выделил на тесте и проме. Но несказать, что это невозможно, всё же несовместимые версии не часто выпускаются. Зато если к руководителю разарботчик 5 раз за год приходит, и говорит, что снова несовместимо поменял API, у руководителя возникнут вопросы к этому разработчику.
Самая сложная проблема в бюрократии: нужно подготовить арх документацию, согласовать всё с безами, выпустить сертификаты, роуты создать, проходы открыть. Вот это действительно проблема. 10 раз подумаешь, нужны ли тебе несовместимые изменеия.
Вообще я бы сказал, что в интерпрайзе несовместимые изменения - редкость. Сделать новое API не проблема, а вот заставить всех потребителей бросить продуктовые задачи и переписывать работающую интеграцию очень не просто.
А зачем объединять месяц и порядковый номер? Почему так же через точку не указать?