Версионность

← →
ORMADA © (2004-08-05 07:15) [0]

Доб утро! Кто знает чё-нить по версионности т.е. допустим чем должна отличаться версия 1.1 от 1.2. и.т.д. ?
вот насчёт 1.0 от 2.0 понятно - типа оч.большое коренное изменение ?

← →
Думкин © (2004-08-05 07:16) [1]

Самое интересное можно прыгнуть с 1.0 на 5.0 - это решаешь только ты и твоя маркетинговая политика.

← →
Sanek_metaller © (2004-08-05 07:17) [2]

Это типа маленькое изменение.

← →
ORMADA © (2004-08-05 07:19) [3]

а есть какие -нить правила именования версий вообще
а то скажем я изменил ну незнаю заголовок окна - всё типа новая версия :)
маркетинговой политики у меня нет и компании тоже спрашиваю чисто для себя

← →
Sanek_metaller © (2004-08-05 07:27) [4]

Смотри совет Думкинa,это тебе решать,что большое изменение,а что маленькое.

← →
Кириешки © (2004-08-05 07:27) [5]

Лично я делаю так - если изменения очень заметны для пользователя
то +1 (от 1.0 до 2.0), а если изменения внесены в код программы, и пользователю их не заметно, то +0.1 (от 1.0 до 1.1).
Вот так.

← →
Vasya.ru (2004-08-05 08:41) [6]

любое маленькое изменение +0.1, изменение интерфейса +1

← →
Alex Konshin © (2004-08-05 08:50) [7]

На самом деле для больших продуктов разделение на версии довольно четкое, оно происходит из самого цикла разработки. Маркетинг только решает, как их назвать. Но вообще-то и тут практически все ясно:
Новая версия - это новый цикл разработки (у нас его зовут stream). Одновременно может разрабатываться несколько стримов одного продукта, например, у нас в компании для основных продуктов одновременно в разработке и поддержке 2-3 версии.
Одна версия находится в стадии планирования - сбора требований (от пользователей, от разработчиков, от маркетинга) и определения того, что должно попасть в новую версию, какой будет график реализации проекта и т.п..
Другая версия находится в активной разработке, т.е. ее активно пишут, тестируют и готовят к выпуску.
Третья версия уже поставляется клиентам и ее нужно поддерживать, т.е. для нее исправляются ошибки и готовятся сервиспаки и maintenance releases.
Например, в подержке версии 6.2.6 и 7.0, в разработке - 8.0, в планировании x-10 (название еще не придумано).

Лучше это дело поставить на поток, версии нумеровать месяца, раз в год наращивать главную цифру. Изменения не обязательны!

версия типа 2.1.5.789

4 число (789) - билд. меняется при каждой компиляции. Обнуляется только со сменой первого числа.
3 число (5) - незначительные изменение, исправления маленьких багов
2 число (1) - значительные изменения, добавление новых возможностей, исправления злостных багов
1 число (2) - ну тут менять понятно как.

1, 2, 3 меняем когда посчитаем нужным или по рассписанию.
4 - сделать автоинкриментным, иначе его трудно назвать Build

Версионность Найти похожие ветки