правильная нумерация версий приложений

 
 
 
Сообщения:347
для нумерации версий моего прилоение использую следующий формат:

<major version>.<minor version>.<incremental version>

например
1.0.1
1.0.2


вскоре номер стал 1.0.9. Вопрос. Какой должна быть следующая версия приложения?
1.0.10 или 1.1.0 ?
 
 
Сообщения:6977
А что, наменяли на изменение минорной версии? Тогда 1.1.0. Нет? 1.0.10.

После 1.0.5 может идти как 1.1.0, так и 2.0.0. Все зависит от количества и качества изменений.

P.S. У меня сейчас версии артефектов - 5.2.0.58, например. А бывало и 4.1.2.1343. :)

С уважением,
Евгений aka Skipy
www.skipy.ru
P.S. Я НЕ решаю задачи ЗА других!
 
 
Сообщения:347
Skipy:
А что, наменяли на изменение минорной версии? Тогда 1.1.0. Нет? 1.0.10.

После 1.0.5 может идти как 1.1.0, так и 2.0.0. Все зависит от количества и качества изменений.

P.S. У меня сейчас версии артефектов - 5.2.0.58, например. А бывало и 4.1.2.1343. :)


что значит наменяли на изменение на минорной версии?
В версии 1.0.9 я пофиксил около 6 багов. Можно ли это считать изменением мнирной версии?
 
 
Сообщения:2428
a_subscriber:

вскоре номер стал 1.0.9. Вопрос. Какой должна быть следующая версия приложения?
1.0.10 или 1.1.0 ?

Если выпуск версии связан с исправлением бага то 1.0.10, если с добавлением ранее не имевшейся функциональности то 1.1.0 если с коренной переделкой приложения то 2.0.0

И не забывайте что нумерация версий не имеет смысла без привязки версий к брэнчам и тегам репозитария исходников.
 
 
Сообщения:862
Я не встречал конвенции или стандарта по указанию версии программы. Программисты которые пишут программу вначале должны определить как версионировать программу. И желательно, чтобы в версии было максимум полезной информации. И исходя из этого определения уже выставлять версию.
Например мне вот такое в голову приходит: версия вида - A.B.C, где
С - просто номер билда копируется
B - увеличивается если в программе добавляется новый функционал или исправляются баги, то есть практически каждый раз когда вылаживается новая версия.
A - увеличивается, если программа теряет совместимость с предыдущей версией. Например там формат файла поменялся рабочего. Или плагины от предыдущей версии не подходят.

Отдельно хотелось упомянуть случай когда за дело берутся маркетологи. В этом случае логика и здравый смысл отступает. Так как раз с Java случилось когда вышла так называемая Java 2.

По поводу сабжа, как по мне делать следующую версию 1.1.0 только из-за того что предыдущая заканчивалась на 9 не логично.
 
 
Сообщения:6977
Pahan:
Например мне вот такое в голову приходит: версия вида - A.B.C, где


У нас было A.B.C.D, где

A - версия поколения (major)
B - версия внутри поколения (minor)
C - версия выпуска (release)
D - сборка (build)

D проставлялась автоматом, C менялась при исправлении багов и добавлении минимальной функциональности, B - при добавлении достаточно большой функциональности. A менялась раз в несколько лет, при кардинальных изменениях.

С уважением,
Евгений aka Skipy
www.skipy.ru
P.S. Я НЕ решаю задачи ЗА других!
 
 
Сообщения:227
Я пользуюсь стандартной мавеновской нумерацией.

Три цифры + SNAPSHOT для версий, которые находятся в разработке.
При релизе увеличиваю последнюю цифру, если выполнялся только фикс багов, вторую - при незначительных изменениях функционала и главную - при значительных изменениях в функционале или изменении в api.
 
 
Сообщения:347
Skipy:
Pahan:
Например мне вот такое в голову приходит: версия вида - A.B.C, где


У нас было A.B.C.D, где

A - версия поколения (major)
B - версия внутри поколения (minor)
C - версия выпуска (release)
D - сборка (build)

D проставлялась автоматом, C менялась при исправлении багов и добавлении минимальной функциональности, B - при добавлении достаточно большой функциональности. A менялась раз в несколько лет, при кардинальных изменениях.


я правильно понимаю, что D может меняться даже если ничего в проекте не изменилось?
 
 
Сообщения:7
Skipy:

D проставлялась автоматом, C менялась при исправлении багов и добавлении минимальной функциональности, B - при добавлении достаточно большой функциональности. A менялась раз в несколько лет, при кардинальных изменениях.


Не подскажите, как сделать автоматическое подставление (автоматический инкремент билда)?
Пользу Eclipse, если это важно.
 
 
Сообщения:831
de-nos:
Не подскажите, как сделать автоматическое подставление (автоматический инкремент билда)?
Пользу Eclipse, если это важно.


Если Вы один работаете над программой и собираете антом, то есть таск <buildnumber/>, который будет хранить число в файле и инкрементировать при каждом выполнении. Собсвенно число доступно как пропертя ${build.number}.
 
 
Сообщения:128
pjotar:
de-nos:
Не подскажите, как сделать автоматическое подставление (автоматический инкремент билда)?
Пользу Eclipse, если это важно.


Если Вы один работаете над программой и собираете антом, то есть таск <buildnumber/>, который будет хранить число в файле и инкрементировать при каждом выполнении. Собсвенно число доступно как пропертя ${build.number}.


В мавене, есть такая возможность? (автоматический инкремент билда).
К примеру, buildnumber должен определять состояние дерева исходников, к примеру, svn revision # (или взять git/hg). Но это предпочтение, другие варианты тоже вполне годятся.
Изменен:01 мая 2013 15:27
 
 
Сообщения:389
s_oleg:
В мавене, есть такая возможность? (автоматический инкремент билда).

Для этой цели служит build number plugin


Поскольку в этом топике еще не упоминалось, - при выборе нумерации версий приложений и библиотек полезно следовать спецификации Semantic Versioning.
 
Модераторы:Нет
Сейчас эту тему просматривают:Нет