#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/
Комментариев нет:
Отправить комментарий