Каким образом у ПО версии определяются?

← →
Ксардас © (2005-09-08 19:45) [0]

Собственно сабж.
Ну чем в принципе могут отличаться версии 1.0.501 от 1.0.503,допустим.
Новой фунцией или просто исправленной ошибкой или как?

← →
Джо © (2005-09-08 19:53) [1]

Тут решает маркетинговый отдел.

← →
AlexWlad © (2005-09-08 19:54) [2]

Сугубо ИМХО.
1-е число - глобальная переработка функциональности
2-е - изменения,дополнения,улучшения отдельных ф-ций
3-е - полировка алгоритмов
4-е - баги.

А впрочем все на совести разработчика.

← →
DrPass © (2005-09-08 21:41) [3]

> Ну чем в принципе могут отличаться версии 1.0.501 от 1.0.503,допустим

Здесь последняя цифра - скорее всего номер билда. Т.е. число, ни к чему не обязывающее. В новой версии может быть исправлена (или наоборот, добавлена) какая-либо ошибка, а могут быть просто незначительные и незаметные для пользователя изменения в коде.

← →
Piter © (2005-09-08 22:46) [4]

Ну тут в линух среде есть определенные правила.

В том числе четный/нечетный номер версии определяет, по-моему, stable и beta версии... не помню уже, там все непросто :)))

← →
Lamer@fools.ua © (2005-09-09 01:24) [5]

>>DrPass © (08.09.05 21:41) [3]

>Здесь последняя цифра - скорее всего номер билда.

Я бы даже не побоялся этого слова - число.

← →
Германн © (2005-09-09 02:10) [6]

"Кассирша Эдита Пьеха отвечает - билетов НЕТ!" (Майк Науменко)

← →
ZeroDivide © (2005-09-09 09:11) [7]

Номер версии отдается на усмотрение выпускающего продукт.
Обычно:
1-ая цифра (Version number) - новая версия продукта.
2 - (Major release) - значительные изменения
3 - (Minor release) - не значительные изменения
4 - (Build) - конкретная сборка.

Различие между значительными и не значительными изменениями очень субъективно. А новая версия - вообще зависит от совести производителя, т.е. когда она ему позволит продавать программму, код которой обычно на 90% остается прежним, как совершенно новую.

Могу рассказать о том, как у нас (а в нашей фирмер есть несколько продуктов, широко известных в мире). Одно могу сказать, что эти числа не берутся с потолка (кроме первых), а определяются самим циклом производства продукта.

Первое и иногда второе число определяют номер релиза. Разные релизы различаются функциональностью. Новая функциональность в продукте появляется только за время от планирования нового релиза до его выпуска и первой отгрузки пользователям (FCS - first customer shipment). В разработке обычно находится сразу несколько главных релизов на разных стадиях. Например, для одного из семейств наших подуктов их сразу три: один в стадии разработки (самый новый), один в стадии поддержки (самый старый) и один между ними в какой-то одной из стадий от разработки до поддержки.
Если следующее число ноль, то это и есть главный релиз (FCS), то есть та версия, которая вперые была поставлена пользователям.
Если же следущее число не ноль, то оно задает номер maintenance release (MOR) или service pack (SP). Это версии, в которых исправляются какие-то ошибки и, возможно, увеличивается производительность. Может незначительно меняться интерфейс. Иногда может добавляться новая функциональность, но только в виде обособленных пакетов, сам продукт при этом не меняется и он обязан сохранять высокую совместимость с предыдущими версиями. Maintenance release поставляется пользователям в виде обновления к главному релизу. Т.е. обычно для того, чтобы поставить эту версию, нужно поставить сначала FCS версию, а потом уже накатить обновление. Хотя иногда заменяется и инсталятор полностью, но возможность upgrade с предыдущей версии и FCS все равно обязана быть.
Следующее число обозначает номер билда. У нас не сквозная нумерация как в MS, а для каждого FCS и MOR релиза своя. Это число имеет значение только для процесса выпуска релиза и для пользователей бессмысленно, т.к. им поставляется только один единственный (финальный) билд релиза.
Что такое билд? Это по сути номер цикла интеграции - построения и тестирования продукта. Т.к. разные группы разрабатывают одновременно, то должен быть некий механизм синхронизации изменений - ведь изменения могут быть (и обычно являются) зависимыми. Поэтому все зависимые изменения должны включаться одновременно в некий билд. Группа интеграции пытается построить продукт и делает быстрое предварительное тестирование основной функционалности. Если сразу не срослось, то это называется blocking issue и то соответствующим программистам нужно срочно, отложив другие дела, исправлить это, и после этого группа интеграции пытается построить следующую итерацию этого билда. Когда это получается - билд становится доступным для всех групп. Разработчики должны использовать его для своей дальнейшей работы.
Группа интеграции ведет одновременно сразу несколько билдов одного и того же релиза в разных стадиях, обычно 2-3. То есть обычно те изменения, что ты сейчас делаешь, будут доступны для всех не ранее, чем через пару билдов. Новый билд стартует как минимум раз в неделю.

Вот такой конвейер.

Номер версии TeX сходится к числу "пи". Каждый раз после внесения изменений к номеру версии добавляется знак числа пи :)

В Red Hat, я могу ошибаться, но второй номер указывает на стабильность версии. Тройка соответствует самой стабильной версии. Так версия 7.3 была выпущена позже 8.0

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

Каким образом у ПО версии определяются? Найти похожие ветки