#php #веб_программирование #cms #контроль_версий #движок
Есть версия ПО 2.9.9
Нужно выпустить новую версию, при этом не хотелось бы переходить на 3.0 Так и не
смог разобраться, под какой версией выпустить ПО?
2.9.10? 2.10.1? 2.9.91?
Да так, чтобы было понятно людям, что эта версия новее предыдущей.
Ответы
Ответ 1
Проблема: вы руководствуетесь принципами визуальной упорядоченности при установке
версии. Версионирование не имеет никаких связей с визуальной упорядоченностью.
Конфликт: вы не можете выбрать между виузальной упорядоченностью, которая говорит
вам сделать 3.0.0, и принципом мажорного релиза, который осознаете скорее всего по-своему,
но понимаете, что мажорный релиз это не "когда все цифры после первой становятся девятками".
Решение: выбрать только одно из двух, потому что принцип мажорной версии запрещает
вам скакать, как получится, а визуальная упорядоченность не дает вам использовать двузначное
число в качестве одного из компонентов версии.
Как все-таки хоть немного программист я могу лишь призвать сделать выбор в пользу
разумного назначения версии. Насколько понял, вы уже читали про семантическое версионирование,
но, судя по комментарию, думаю, что попытаться адаптировать конвенцию для вас стоит.
Семантическая версия состоит из трех номеров: major, minor, patch. Они различаются
следующими вещами:
patch-версия инкрементируется при выпуске релиза, закрывающего баги
minor-версия инкрементируется при выпуске релиза с новым функционалом, не затрагивающем
старый
major версия инкрементируется при выпуске релиза, которым невозможно пользоваться
так, как прежде
Поэтому определение "какую версию мне использовать" превращается в довольно простой
условный блок:
Релиз содержит только багфиксы? Инкрементируется patch-компонент, 2.9.10
Релиз содержит нововведения, но старый функционал остался прежним? 2.10.0
Релиз содержит нововведения, которые меняют способ использования старого функционала?
3.0.0
Отвечая на вопрос, который тут же появляется - "мне что, инкремнтировать major-версию
каждый раз, когда я ломаю обратную совместимость?". Ответ на этот вопрос - да, major-версия
должна выпускаться каждый раз, когда какие-то вещи ломаются; это не игра в поддавки
и визуальную упорядоченность. Если вас заботит скорость выпуска major-версий - это
значит, что вы ломаете слишком много вещей, и какие-то обновления стоит придерживать
в ветке до того, как появится моральная готовность выпустить новый major-релиз; на
адаптацию к этой модели уйдет некоторое время, но на деле это всего лишь цифры, между
которыми нет никакой разницы, версия 2.х.х или 17.х.х - для конечного потребителя это
не так важно как то, сможет ли он пользоваться новой версией так же, как старой.
Не пытайтесь воспринимать 2.9.9. как 299. Это не число и не поддается правилам инкрементирования
чисел.
Ответ 2
2.9.91 - самое понятное решение. Если бы вы использовали настроенную систему контроля
версий, то она сама бы дала нужные цифры (скорее всего, другие).
Вот один из наиболее распространенных подходов:
Формат номера версии A.B.C.D[r], где:• A – главный номер версии (major
version number). • B – вспомогательный номер версии (minor version
number). • C – номер сборки, номер логической итерации по работе над
функционалом версии A.B (build number). • D – Номер ревизии, сквозной
номер назначаемый автоматически программным обеспечением хранения
версий (SVN). Номер ревизии SVN должен синхронизироваться с номером
ревизии в AssemblyInfo при каждой сборке релиза (revision number). •
[r] – условное обозначение релиза.
Подробнее - https://habrahabr.ru/post/119400/
