Что обычно обозначают цифры в версии (т.е.v1.9.0.1)?
https://stackoverflow.com/questions/65718
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Возможно, это глупый вопрос, но я всегда предполагал, что каждое число, отмеченное точкой, представляет собой отдельный компонент программного обеспечения.Если это правда, представляют ли они когда-нибудь что-то другое?Я хотел бы начать назначать версии различным сборкам моего программного обеспечения, но я не совсем уверен, как это должно быть структурировано.Мое программное обеспечение состоит из пяти различных компонентов.
Решение
В версии 1.9.0.1:
1:Основная переработка (новый пользовательский интерфейс, множество новых функций, концептуальные изменения и т. д.)
9:Небольшая доработка (возможно, изменение поля поиска, добавление 1 функции, набор исправлений ошибок)
0:Выпуск с исправлением ошибок
1:Номер сборки (если используется) — поэтому вы видите, что платформа .NET использует что-то вроде 2.0.4.2709.
Вы не найдете много приложений, опускающихся до четырех уровней, обычно достаточно 3.
Другие советы
Здесь Спецификация семантического управления версиями
Это краткое изложение версии 2.0:
Учитывая номер версии MAJOR.MINOR.PATCH, увеличьте:
MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes.Дополнительные этикетки для метаданных предварительных выпусков и сборки доступны в качестве расширений в формате major.minor.patch.
Он может быть очень произвольным и различаться от продукта к продукту.Например, в дистрибутиве Ubuntu версия 8.04 относится к апрелю 2008 года.
Обычно самые левые (основные) цифры указывают на основной выпуск, и чем дальше вы идете вправо, тем меньшие изменения вносятся в него.
основной.второстепенный[.обслуживание[.сборка]]
Числа могут быть полезны, как описано в других ответах, но подумайте, что они также могут быть довольно бессмысленными...Сан, ты знаешь СОЛНЦЕ, ява:1,2, 1,3, 1,4, 1,5 или 5, затем 6.В старом добром Apple II номера версий что-то значили.В настоящее время люди отказываются от номеров версий и используют глупые названия, такие как «Злющий инжир» (или что-то в этом роде), «Выносливая цапля», «Европа» и «Ганимед».Конечно, это гораздо менее полезно, потому что у вас закончатся спутники Юпитера, прежде чем вы перестанете изменять программу, а поскольку нет очевидного порядка, вы не можете сказать, какой из них новее.
Чем больше баллов, тем более незначительным будет релиз.Помимо этого, не существует настоящего твердого стандарта - это может означать разные вещи в зависимости от того, что решают сопровождающие проекта.
WordPress, например, действует следующим образом:
1.6 -> 2.0 -> 2.0.1 -> 2.0.2 -> 2.1 -> 2.1.1 -> 2.2 ...
Версия 1.6–2.0 будет большим релизом — функции, изменения интерфейса, серьезные изменения в API, поломка некоторых шаблонов и плагинов версии 1.6 и т. д.Версия 2.0–2.0.1 будет второстепенным выпуском, возможно, исправляющим ошибку безопасности.Обновления с 2.0.2 по 2.1 будут значительным выпуском - в целом, с новыми функциями.
Цифры могут означать все, что вы хотите, хотя обычно они связаны не с отдельными компонентами, а скорее с основными, а не с основными компонентами.минор против.изменения в сопровождении вашего выпуска.
Посмотрите эти ресурсы:
http://www.netbeans.org/community/guidelines/process.html
http://en.wikipedia.org/wiki/Release_engineering
http://www.freebsd.org/releases/6.0R/schedule.html
Ваше здоровье
Номера версий обычно не представляют собой отдельные компоненты.Для некоторых людей/программного обеспечения цифры довольно произвольны.Для других разные части строки номера версии представляют разные вещи.Например, некоторые системы увеличивают часть номера версии при изменении формата файла.Таким образом, формат файла V 1.2.1 совместим со всеми остальными версиями V 1.2 (1.2.2, 1.2.3 и т. д.), но не с V 1.3.В конечном итоге вам решать, какую схему вы хотите использовать.
Это зависит от ситуации, но типичным представлением является представление основной.второстепенный.релиз.билд.
Где:
- главный это основная версия вашего программного обеспечения, например .NET 3.x.
- незначительный это дополнительная версия вашего программного обеспечения, например .NET x.5.
- выпускать является выпуском этой версии, обычно исправления ошибок увеличивают ее
- строить — это число, обозначающее количество выполненных вами сборок.
Например, 1.9.0.1 означает, что это версия вашего программного обеспечения 1.9, следующая за 1.8, 1.7 и т. д.где версии 1.7, 1.8 и 1.9 каким-то образом обычно добавляют небольшое количество новых функций наряду с исправлениями ошибок.Поскольку это x.x.0.x, это начальный выпуск 1.9 и первая сборка этой версии.
Вы также можете найти полезную информацию на Статья в Википедии на эту тему.
Основные.Минорные.Ошибки
(Или какой-то вариант на эту тему)
Ошибки обычно представляют собой исправления ошибок без каких-либо новых функций.
Незначительное — это некоторое изменение, которое добавляет новые функциональные возможности, но не меняет программу каким-либо существенным образом.
Крупное изменение в программе, которое либо нарушает старые функциональные возможности, либо настолько велико, что каким-то образом меняет способ использования программы пользователями.
В файле C# AssemblyInfo.cs вы можете увидеть следующее:
// Version information for an assembly consists of the following four values:
//
// Major Version
// Minor Version
// Build Number
// Revision
//
/ You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
Я думаю, что Release.major.minor.revision.
Но оно может сильно различаться в зависимости от продукта.
Major.minor.point.build обычно.Основные и второстепенные говорят сами за себя, точка — это выпуск с несколькими незначительными исправлениями ошибок, а сборка — это просто идентификатор сборки.
Обычно это:
MajorVersion.MinorVersion.Revision.Build
Ага.Основные выпуски добавляют большие новые функции, могут нарушать совместимость или иметь существенно отличающиеся зависимости и т. д.
Второстепенные выпуски также добавляют функции, но они представляют собой меньшие по размеру, иногда урезанные портированные версии из основной бета-версии.
Если есть третий компонент номера версии, он обычно предназначен для важных исправлений ошибок и исправлений безопасности.Если их больше, то это действительно настолько сильно зависит от продукта, что сложно дать общий ответ.
Каждый сам выбирает, что ему делать с этими числами.У меня возникло искушение назвать релизы a.b.c, потому что это в любом случае довольно глупо.При этом то, что я видел за последние 25 с лишним лет разработки, имеет тенденцию работать именно так.Допустим, ваш номер версии — 1.2.3.
«1» указывает на «основную» версию.Обычно это первоначальный выпуск, большое изменение набора функций или переписывание значительных частей кода.Как только набор функций определен и хотя бы частично реализован, вы переходите к следующему номеру.
«2» указывает на выпуск в серии.Часто мы используем эту позицию, чтобы ухватиться за функции, которых не было в последнем крупном выпуске.Эта позиция (2) почти всегда указывает на добавление функции, обычно с исправлением ошибок.
«3» в большинстве магазинов указывает на выпуск патча или исправление ошибки.Почти никогда, по крайней мере с коммерческой стороны, это не указывает на существенное добавление функций.Если функции отображаются на позиции 3, возможно, это связано с тем, что кто-то что-то проверил до того, как мы узнали, что нам нужно выпустить выпуск с исправлением ошибок.
За пределами позиции «3»?Я понятия не имею, почему люди делают такие вещи, это только сбивает с толку.
Примечательно, что некоторые сотрудники УСС выводят все это из строя.Например, версия Trac 10 на самом деле — это 0.10.X.X.Я думаю, что многим людям в мире OSS либо не хватает уверенности, либо они просто не хотят объявлять о том, что у них есть крупный релиз.
Я думаю, что парадигма Major Release.Minor Release.Bug Fix довольно распространена.
В некоторых контрактах на корпоративную поддержку предусмотрены $$$ (или нарушение контрактной ответственности), связанные с обозначением конкретной версии.Контракт, например, может давать клиенту право на некоторое количество основных выпусков в течение определенного периода времени или обещать, что второстепенных выпусков будет меньше, чем x, или что поддержка будет по-прежнему доступна для такого количества релизы.Конечно, сколько бы слов ни было вложено в контракт, чтобы объяснить, чем является основной выпуск по сравнению с второстепенным выпуском, это всегда субъективно, и всегда будут существовать серые зоны, что приводит к возможности того, что поставщик программного обеспечения может заставить систему обмануть систему. превзойти такие договорные положения.
Люди не всегда осознают тонкую разницу между номерами версий, например 2.1, 2.0.1 или 2.10. Спросите специалиста службы технической поддержки, сколько раз у них с этим возникали проблемы.Разработчики ориентированы на детали и знакомы с иерархическими структурами, поэтому для нас это «слепое пятно».
Если это вообще возможно, предоставьте своим клиентам более простой номер версии.
В случае библиотеки номер версии говорит вам о уровень совместимости между двумя выпусками и, следовательно, насколько трудным будет обновление.
Версия с исправлением ошибок должна сохранять совместимость двоичных файлов, исходных кодов и сериализации.
Второстепенные выпуски означают разные вещи для разных проектов, но обычно им не требуется сохранять совместимость исходного кода.
Номера основных версий могут нарушить все три формы.
Я написал подробнее о причине здесь.
В версии v1.9.0.1:Это явная схема управления версиями используется, когда вы не хотите использовать имя для предварительных выпусков или сборок типа -alpha,-beta.
1: Основная версия, которая может нарушить обратную совместимость.
9: Добавление новых функций для поддержки вашего приложения, а также обратная совместимость с предыдущей версией.
0:Некоторые мелкие исправления ошибок.
1: Номер сборки (номер предварительной версии)
но в настоящее время вы не найдете такой схемы управления версиями. Обратитесь к Semantic Versioning [semver2.0]https://semver.org/
Комбинация основных, второстепенных, исправлений, сборок, исправлений безопасности и т. д.
Первые два — основные и второстепенные, остальное будет зависеть от проекта, компании и иногда сообщества.В таких ОС, как FreeBSD, у вас будет номер 1.9.0.1_number для обозначения исправления безопасности.
Немного зависит от языка, например, Delphi и C# имеют разные значения.
Обычно первые две цифры обозначают мажорную и минорную версию, т.е.1.0 для первого реального выпуска, 1.1 для некоторых важных исправлений ошибок и небольших новых функций, 2.0 для большого выпуска новых функций.
Третье число может относиться к «действительно незначительной» версии или редакции.Например, версия 1.0.1 — это очень небольшое исправление ошибки по сравнению с версией 1.0.0.Но он также может содержать номер версии из вашей системы управления версиями или постоянно увеличивающийся номер, который увеличивается с каждой сборкой.Или штамп даты.
Немного подробнее здесь.«официально» в .net 4 числа — это «Major.Minor.Build.Revision», тогда как в Delphi есть «Major.Minor.Release.Build».Для управления версиями я использую «Major.Minor.ReallyMinor.SubversionRev».
Обычно номера имеют формат version.major.minor.hotfix, а не отдельные внутренние компоненты.Таким образом, v1.9.0.1 будет версией 1, основным выпуском 9 (v1), дополнительным выпуском (v1.9) 0, исправлением 1 (v1.9.0).
Первый номер обычно называют основным номером версии.В основном он используется для обозначения значительных изменений между сборками (т.когда вы добавляете много новых функций, вы увеличиваете основную версию).Компоненты одного и того же продукта с разными основными версиями, вероятно, несовместимы.
Следующее число — это дополнительный номер версии.Он может представлять собой некоторые новые функции, ряд исправлений ошибок или небольшие изменения в архитектуре.Компоненты одного и того же продукта, которые отличаются младшим номером версии, могут работать или не работать вместе и, вероятно, не должны.
Следующий обычно называется номером сборки.Это значение может увеличиваться ежедневно, с каждой «выпущенной» сборкой или вообще с каждой сборкой.Могут быть лишь небольшие различия между двумя компонентами, которые отличаются только номером сборки и обычно могут хорошо работать вместе.
Последнее число обычно является номером версии.Часто это используется в процессе автоматической сборки или когда вы создаете «одноразовые» одноразовые сборки для тестирования.
Когда вы увеличиваете номера версий, зависит от вас, но они всегда должны приращение или оставайся таким же.Вы можете сделать так, чтобы все компоненты имели один и тот же номер версии, или увеличивали номер версии только для измененных компонентов.
Номер версии сложного программного обеспечения представляет собой весь пакет и не зависит от номеров версий его частей.Версия Gizmo 3.2.5 может содержать Foo версии 1.2.0 и Bar версии 9.5.4.
При создании номеров версий используйте их следующим образом:
Первый номер — основной выпуск.Если вы вносите значительные изменения в пользовательский интерфейс или вам необходимо сломать существующие интерфейсы (чтобы вашим пользователям пришлось изменить код своего интерфейса), вам следует перейти на новую основную версию.
Второе число должно указывать на то, что были добавлены новые функции или что-то внутри работает по-другому.(Например, база данных Oracle может решить использовать другую стратегию получения данных, что сделает большинство операций быстрее, а некоторые медленнее.) Существующие интерфейсы должны продолжать работать, а пользовательский интерфейс должен быть узнаваемым.
Дальнейшая нумерация версий остается на усмотрение человека, пишущего программу — Oracle использует пять (!) групп, т.е.версия Oracle — это что-то вроде 10.1.3.0.5.Начиная с третьей группы, вам следует вносить только исправления ошибок или незначительные изменения в функциональности.
те, которые различаются меньше, - это первые два, для major.minor, после этого это может быть что угодно: от сборки, версии, выпуска до любых пользовательских алгоритмов (например, в некоторых продуктах MS)
Каждая организация/группа имеет свой собственный стандарт.Важно то, что вы придерживаетесь выбранных вами обозначений, иначе ваши клиенты будут сбиты с толку.Сказав, что я обычно использовал 3 цифры:
x.yz.bbbbb.Где:Икс:является основной версией (крупные новые функции) y:является второстепенным номером версии (небольшие новые функции, небольшие улучшения без изменений пользовательского интерфейса) z:Пакет обслуживания (в основном такой же, как xy, но с некоторыми исправлениями ошибок BBBB:— это номер сборки, который действительно виден только в окне «О программе» вместе с другими сведениями для поддержки клиентов.bbbb — это свободный формат, и каждый продукт может использовать свой собственный.
Вот что мы используем:
- Первое число = общая эпоха системы.Изменения происходят каждые пару лет и обычно представляют собой фундаментальные изменения в технологии или функциях клиента, или и то, и другое.
- Второе число = версия схемы базы данных.Увеличение этого числа требует миграции базы данных и, следовательно, является значительным изменением (или системы реплицируются, и поэтому изменение структуры базы данных требует тщательного процесса обновления).Сбрасывается в 0, если меняется первое число.
- Третья цифра = только изменение программного обеспечения.Обычно это можно реализовать для каждого отдельного клиента, поскольку схема базы данных не изменяется.Сбрасывается в ноль, если меняется второе число.
- Номер версии Subversion.Мы заполняем это автоматически при сборке с помощью инструмента TortoiseSVN.Это число никогда не сбрасывается, а постоянно увеличивается.Используя это, мы всегда можем воссоздать любую версию.
Эта система хорошо нам служит, потому что каждое число имеет четкую и важную функцию.Я видел, как другие команды пытались решить вопрос «старшее/второстепенное число» (насколько большое изменение является значительным), и я не вижу в этом никакой пользы.Если вам не нужно отслеживать версии базы данных, просто перейдите к трехзначному или двухзначному номеру версии и облегчите жизнь!
