Как лучше нумеровать релизы? Где можно почитать, или подскажите на вашем опыте, как лучше называть нумерацию версий программы?
Например, есть несколько сервисов на продакшине, но над ними регулярно ведется работа, пока-что мысли по нумерации такие:
Номер версии это 4 числа разделенные точками, (например: 1.2.3.4), где повышение цифры означает:
1. (пример: 2.0) Глобальный релиз: когда весь сервис переписывается с нуля. С изменениями дизайна, API, и т.д.
2. (пример: 1.2) Очередной резлиз версии 1, в котором много что изменилось, мог поменяться интерфейс. API при изменении мог потерять часть обратной совместимости и т.д.
3. (пример: 1.2.1) Подрелиз 1.2. Небольшие правки, в основном багфиксы плюс некоторые новые фитчи. Полная обратная совместимость API.
4. (Пример: 1.2.1.38) Внутренний подрелиз (не знаю применим ли термин релиз в данном случае), очередной шаг к выпуску версии 1.2.2. В проде цифры после третей ссылки нигде не фигурируют.
Это то к чему я пришел на данный момент, но может есть какие-нибудь стандарты как это должно быть на самом деле? Поправьте пожалуйста мою схему, особенно если в ней есть серьезные просчеты.
Заранее спасибо )
Как лучше нумеровать релизы? Где можно почитать, или подскажите на вашем опыте, как лучше называть нумерацию версий программы?
Например, есть несколько сервисов на продакшине, но над ними регулярно ведется работа, пока-что мысли по нумерации такие:
Номер версии это 4 числа разделенные точками, (например: 1.2.3.4), где повышение цифры означает:
1. (пример: 2.0) Глобальный релиз: когда весь сервис переписывается с нуля. С изменениями дизайна, API, и т.д.
2. (пример: 1.2) Очередной резлиз версии 1, в котором много что изменилось, мог поменяться интерфейс. API при изменении мог потерять часть обратной совместимости и т.д.
3. (пример: 1.2.1) Подрелиз 1.2. Небольшие правки, в основном багфиксы плюс некоторые новые фитчи. Полная обратная совместимость API.
4. (Пример: 1.2.1.38) Внутренний подрелиз (не знаю применим ли термин релиз в данном случае), очередной шаг к выпуску версии 1.2.2. В проде цифры после третей ссылки нигде не фигурируют.
Это то к чему я пришел на данный момент, но может есть какие-нибудь стандарты как это должно быть на самом деле? Поправьте пожалуйста мою схему, особенно если в ней есть серьезные просчеты.
Заранее спасибо )
Например, есть несколько сервисов на продакшине, но над ними регулярно ведется работа, пока-что мысли по нумерации такие:
Номер версии это 4 числа разделенные точками, (например: 1.2.3.4), где повышение цифры означает:
1. (пример: 2.0) Глобальный релиз: когда весь сервис переписывается с нуля. С изменениями дизайна, API, и т.д.
2. (пример: 1.2) Очередной резлиз версии 1, в котором много что изменилось, мог поменяться интерфейс. API при изменении мог потерять часть обратной совместимости и т.д.
3. (пример: 1.2.1) Подрелиз 1.2. Небольшие правки, в основном багфиксы плюс некоторые новые фитчи. Полная обратная совместимость API.
4. (Пример: 1.2.1.38) Внутренний подрелиз (не знаю применим ли термин релиз в данном случае), очередной шаг к выпуску версии 1.2.2. В проде цифры после третей ссылки нигде не фигурируют.
Это то к чему я пришел на данный момент, но может есть какие-нибудь стандарты как это должно быть на самом деле? Поправьте пожалуйста мою схему, особенно если в ней есть серьезные просчеты.
Заранее спасибо )
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Ваш подход к нумерации версий программы выглядит вполне осмысленным и логичным. Однако, стандарты нумерации версий могут немного отличаться в зависимости от конкретного проекта или компании. В целом, ваша схема с использованием 4 чисел разделенных точками довольно стандартна и может быть успешно применена.
Если вы хотите ознакомиться с более общепринятыми стандартами нумерации версий программ, вам стоит обратить внимание на Semantic Versioning (SemVer), который предлагает схему нумерации версий в формате "MAJOR.MINOR.PATCH", где:
MAJOR увеличивается при совместимых изменениях, которые делают невозможным обновление без изменений в API;MINOR увеличивается при добавлении новой функциональности, которая сохраняет совместимость с предыдущими версиями;PATCH увеличивается при исправлении ошибок и внесении мелких изменений.Для более подробной информации вы можете посетить официальный сайт Semantic Versioning (https://semver.org/) или почитать дополнительные материалы по этой теме.
Независимо от выбранной схемы, важно иметь четкое понимание того, какие изменения вносятся в каждую версию и как это отражается на пользователей и другие сервисы. Ваши четкие определения для каждого уровня версии помогут вам и вашей команде лучше понимать процесс выпуска обновлений и обеспечивать обратную совместимость по мере возможности.