Comments 21
<Старший номер версии>.<Младший номер версии>.<Номер ревизии в системе контроля версий>.<Порядковый номер релизного билда с начала разработки>
UFO landed and left these words here
А вот мне интересно: как вы определяете, что уже пора переходить на новую 'старшую версию'?
UFO landed and left these words here
Вот именно. А вообще никто не запрещает их от балды взять, зато последние два очень полезны — помогают откатить исходники к нужной ревизии и оценить продолжительность разработки.
UFO landed and left these words here
major.minor, если поправка единственного бага/единственная доработка — major.minor.fix
Бывает несколько билдов в день, так что такая нумерация проблематична…
В рамках дипломной работы разрабатываю специализированную поисковую систему. По сравнению с обычными web-проектами у неё есть особенность: пользователь работает с системой read-only. Эта особенность учтена при нумерации.

Другая, более общая, специфика проекта это то, что размещается он на AWS, поэтому номера я даю образам.

Используется следующая схема:
X.Y.Z, где
X — изменения проекта, которые сразу бросаются в глаза пользователю
Y — внутренние изменения, которые затрагивают только качество поиска
Z — обновления базы (индекса)

В системе контроля версий используются либо тэги, либо бранчи, которые соответствуют X.Y
Использую:
— для веб-приложений X.Y.Z
— для древних арм-ов (сопровождать проще, чем переписывать) X.Y.Z.YYYYMMDD

Как то так.
Windows installer не понимает больше x.y.z :(. Поэтому в целях совместимости везде использую major.minor.build. Выглядит, конечно, косолапо — зато гарантирует отсутствие проблемм при развертывании. Ну или хотя бы пытается :).
Only those users with full accounts are able to leave comments. Log in, please.