Что обычно представляют цифры в версии (т.е. v1.9.0.1)? - PullRequest
114 голосов
/ 15 сентября 2008

Может быть, это глупый вопрос, но я всегда предполагал, что каждое число, обозначенное точкой, представляет отдельный компонент программного обеспечения. Если это правда, они когда-нибудь представляют что-то другое? Я хотел бы начать присваивать версии различным сборкам моего программного обеспечения, но я не совсем уверен, как это должно быть структурировано. Мое программное обеспечение состоит из пяти отдельных компонентов.

Ответы [ 29 ]

2 голосов
/ 15 сентября 2008

Major.Minor.Bugs

(или что-то в этом роде)

Ошибки - это, как правило, исправления ошибок без новой функциональности.

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

Major - это изменение в программе, которое либо нарушает старые функции, либо настолько велико, что каким-то образом меняет способ использования программы пользователями.

2 голосов
/ 15 сентября 2008

Зависит, но типичным представлением является major.minor.release.build .

Где:

  • major является основной версией вашего программного обеспечения, подумайте .NET 3.x
  • minor - это версия вашего программного обеспечения, выпущенная в минорном выпуске, подумайте .NET x.5
  • release - выпуск этой версии, обычно исправления ошибок увеличивают это
  • build - это число, которое обозначает количество выполненных вами сборок.

Так, например, 1.9.0.1 означает, что это версия вашего программного обеспечения 1.9, следующая за 1.8 и 1.7 и т. Д., Где 1.7, 1.8 и 1.9 все в некотором роде обычно добавляют небольшое количество новых функций наряду с исправлениями. Поскольку это x.x.0.x, это начальный выпуск 1.9, и это первая сборка этой версии.

Вы также можете найти хорошую информацию в статье Википедии на эту тему .

1 голос
/ 15 сентября 2008

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

Незначительные выпуски также добавляют функции, но они меньше, иногда урезанные портированные версии из бета-версии.

Если есть третий компонент номера версии, он обычно для важных исправлений и исправлений безопасности. Если их больше, это действительно так сильно зависит от продукта, что сложно дать общий ответ.

1 голос
/ 15 сентября 2008

Обычно это:

MajorVersion.MinorVersion.Revision.Build

1 голос
/ 15 сентября 2008

Major.minor.point.build обычно. Основные и второстепенные говорят сами за себя, точка - это исправление нескольких незначительных ошибок, а сборка - это просто идентификатор сборки.

1 голос
/ 15 сентября 2008

Каждый выбирает, что он хочет делать с этими числами. Я испытывал желание называть релизы a.b.c, так как это все равно довольно глупо. При этом то, что я видел за последние 25 с лишним лет разработки, имеет тенденцию работать таким образом. Допустим, номер вашей версии 1.2.3.

«1» обозначает «основную» ревизию. Обычно это первоначальный выпуск, большое изменение набора функций или переписывание значительных частей кода. Как только набор функций определен и хотя бы частично реализован, вы переходите к следующему номеру.

«2» указывает на выпуск в серии. Часто мы используем эту позицию, чтобы освоить функции, которые не были реализованы в последнем основном выпуске. Эта позиция (2) почти всегда указывает на добавление функции, обычно с исправлениями ошибок.

"3" в большинстве магазинов указывает на выпуск патча / исправление ошибки. Почти никогда, по крайней мере, на коммерческой стороне, это не указывает на существенную добавленную функцию. Если функции появляются в позиции 3, то, возможно, это связано с тем, что кто-то проверил что-то, прежде чем мы узнали, что нам нужно выпустить исправление ошибки.

За позицией «3»? Я понятия не имею, почему люди делают такие вещи, это только сбивает с толку.

Примечательно, что некоторые из OSS там выбрасывают все это в тупик. Например, версия 10 Trac на самом деле 0.10.X.X. Я думаю, что многие люди в мире OSS либо не уверены в себе, либо просто не хотят объявлять о том, что они сделали основной релиз.

1 голос
/ 04 декабря 2018

В версии v1.9.0.1: Это явная схема управления версиями , используемая, когда вы не хотите использовать имя для предварительных выпусков или сборку, например -alpha, -beta.

1: основная версия, которая может нарушить обратную совместимость

9: добавление новых функций для поддержки вашего приложения и обратной совместимости с предыдущей версией.

0: исправлены незначительные ошибки

1: номер сборки (номер предварительной версии)

но в настоящее время вы не найдете такой схемы управления версиями. См. Семантическое управление версиями [semver2.0] https://semver.org/

1 голос
/ 28 ноября 2010

В случае библиотеки номер версии сообщает вам об уровне совместимости между двумя выпусками и, следовательно, насколько сложным будет обновление.

Выпуск исправления ошибки должен сохранять совместимость двоичного кода, источника и сериализации.

Незначительные релизы означают разные вещи для разных проектов, но обычно им не нужно сохранять совместимость с исходным кодом.

Основные номера версий могут разбить все три формы.

Я написал больше об обосновании здесь .

1 голос
/ 15 сентября 2008

Я думаю, что парадигма основного исправления release.minor release.bug довольно распространена.

В некоторых контрактах на поддержку предприятий существует $$$ (или нарушение обязательств по контракту), связанные с определением конкретного выпуска. Например, контракт может дать клиенту право на некоторое количество основных выпусков за определенный период времени или пообещать, что в течение определенного периода будет выпадать менее x количества второстепенных выпусков или что поддержка будет по-прежнему доступна для многих релизы. Конечно, независимо от того, сколько слов вставлено в контракт для объяснения того, что является основным выпуском по сравнению с второстепенным выпуском, он всегда субъективен и всегда будет иметь серые области, что приведет к возможности того, что поставщик программного обеспечения сможет настроить систему на бить такие договорные положения.

1 голос
/ 25 сентября 2008

Люди не всегда распознают тонкую разницу между номерами версий, такими как 2.1, 2.0.1 или 2.10 - спросите специалиста службы технической поддержки, сколько раз у них были проблемы с этим. Разработчики ориентированы на детали и знакомы с иерархическими структурами, поэтому для нас это слепое пятно.

Если это вообще возможно, предоставьте своим клиентам более простой номер версии.

...