Какая должна быть нумерация релизов для сервисов?

Question

[The_Pro_Killer]

Вопрос, возможно, покажется тупым:)
Есть, условно, 10 микросервисов, в каждом из которых постоянно создаются релизные ветки (release/2.0, release/2.1, release/2.2 и т.д.). Но возникла ситуация, что в некоторых сервисах из релиза в релиз вообще нет никаких изменений и в нем просто "тупо" добавляется очередная ветка release/'..' . Может быть есть какой-то best practice для таких случаев, по типу другого наименования (версионирования) релизных веток или что-то еще, чтобы "отдыхающие от изменений" сервисы не были вообще тронуты? Заранее спасибо!

Answer 1

[Максим Федоров]

Если сервис не обновляется, ему не нужно поднимать версию

В целом версии ведутся по semver, через теги

Answer 2

[Saboteur]

Делайте или семантическое версионирование, если нужно отслеживать совместимость между сервисами.

Или просто номер релиза в этом году, типа 2023.1, 2023.2

Кроме того, номер релиза может не совпадать с версией компонентов, входящих в этот релиз, можно и не делать их одинаковыми

Answer 3

[Владимир Коротенко]

Просто воруйте хорошие идеи

1.2.3

Где 1 главная версия которая что то сможет сломать и видимо обязательно сломает
Где 2 типа ветка где могут быт предупреждения о деприкатед и в общем то перейди на новые кострукции
Где 3 Вообще без вопросов обновляешься