что обычно представляют цифры в версии (т.е. v1.9.0.1)?

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

<p>в версии <em>1.9.0.1</em>:</p><ul> <li><p><strong> 1 </strong>: основные изменения (новый пользовательский интерфейс, множество новых функций, концептуальные изменения и т.д.)</p></li> <li><p><strong> 9 </strong>: незначительная ревизия (возможно, изменение поля поиска, добавлена 1 функция, исправлены ошибки)</p></li> <li><p><strong> 0 </strong>: исправление ошибок</p></li> <li><p><strong> 1 </strong>: номер сборки (если используется) - вот почему вы видите .net framework, используя что-то вроде 2.0.4.2709</p></li> </ul><p>вы не найдете много приложений, спускающихся до четырех уровней, обычно достаточно 3.</p>

<p>существует <a href="https://semver.org/">спецификация семантического управления версиями</a> </p><p>это краткое изложение версии 2.0:</p><blockquote> <p>учитывая номер версии major.minor.patch, увеличьте:</p> <pre><code>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. </code></pre> <p>дополнительные метки для предварительной версии и метаданных сборки доступны как расширения в формате major.minor.patch.</p> </blockquote>

<p>это может быть очень произвольно, и отличается от продукта к продукту. например, в дистрибутиве ubuntu 8.04 относится к 2008 году. апрель</p><p>как правило, самые левые (основные) числа указывают на основной выпуск, и чем дальше вы идете направо, тем меньше будет вовлечено изменение.</p>

<p>major.minor [.maintenance [.build]]</p><p> <a href="http://en.wikipedia.org/wiki/software\_versioning#numeric">http://en.wikipedia.org/wiki/software\_versioning#numeric</a> </p>

<p>числа могут быть полезны, как описано в других ответах, но подумайте о том, что они также могут быть довольно бессмысленными ... sun, вы знаете sun, java: 1.2, 1.3, 1.4 1.5 или 5, а затем 6 .... в старом добром apple ii номера версий имели в виду что-то. в настоящее время люди отказываются от номеров версий и идут с глупыми именами, такими как «feisty fig» (или что-то в этом роде) и «hardy heron», «europa» и «ganymede». конечно, это гораздо менее полезно, потому что у вас кончится спутник юпитера, прежде чем вы перестанете менять программу, и, поскольку нет очевидного порядка, вы не можете сказать, что новее.</p>

<p>чем больше очков, тем незначительнее релиз. за этим не существует реального твердого стандарта - это может означать разные вещи в зависимости от того, что решают сопровождающие проекта.</p><p>wordpress, например, идет по следующим направлениям:</p><p>1.6 -> 2.0 -> 2.0.1 -> 2.0.2 -> 2.1 -> 2.1.1 -> 2.2 ...</p><p>1.6 - 2.0 - это большой выпуск - функции, изменения интерфейса, серьезные изменения в api, поломка некоторых шаблонов и плагинов 1.6 и т.д. с 2.0 по 2.0.1 - это второстепенный выпуск, возможно, исправление ошибки безопасности. 2.0.2 до 2.1 будет значительным выпуском - вообще новые функции.</p>

<p>числа могут означать все, что вы захотите, хотя обычно они связаны не с отдельными компонентами, а скорее с основными, второстепенными или техническими изменениями в вашем выпуске.</p><p>проверьте эти ресурсы:<br> <a href="http://www.netbeans.org/community/guidelines/process.html">http://www.netbeans.org/community/guidelines/process.html</a> <br> <a href="http://en.wikipedia.org/wiki/release\_engineering">http://en.wikipedia.org/wiki/release\_engineering</a> <br> <a href="http://www.freebsd.org/releases/6.0r/schedule.html">http://www.freebsd.org/releases/6.0r/schedule.html</a> </p><p>ура</p>

<p>номера версий обычно не представляют отдельные компоненты. для некоторых людей/программного обеспечения цифры довольно условны. для других, разные части строки номера версии представляют разные вещи. например, некоторые системы увеличивают части номера версии при изменении формата файла. таким образом, v 1.2.1 является форматом файла, совместимым со всеми другими версиями v 1.2 (1.2.2, 1.2.3 и т.д.), но не с v 1.3. в конечном итоге вам решать, какую схему вы хотите использовать.</p>

<p>из файла c # assemblyinfo.cs вы можете увидеть следующее:</p><pre><code>// 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.*")] </code></pre>

<p>release.major.minor.revision было бы моим предположением.<br> но это может сильно отличаться между продуктами.</p>

<p>это зависит, но типичным представлением является <em>major.minor.release.build</em>.</p><p>куда:</p><ul> <li><em>major</em> является основной версией вашего программного обеспечения, подумайте .net 3.x</li> <li><em>minor</em> является минорной версией вашего программного обеспечения, подумайте .net x.5</li> <li><em>release</em> является выпуском этой версии, обычно исправления ошибок увеличивают это</li> <li><em>build</em> - это число, которое обозначает количество выполненных вами сборок.</li> </ul><p>так, например, 1.9.0.1 означает, что это версия вашего программного обеспечения 1.9, следующая за 1.8 и 1.7 и т.д., где 1.7, 1.8 и 1.9 все в некотором роде обычно добавляют небольшое количество новых функций наряду с исправлениями ошибок. поскольку это x.x.0.x, это начальный выпуск 1.9, и это первая сборка этой версии.</p><p>вы также можете найти хорошую информацию в <a href="http://en.wikipedia.org/wiki/software\_versioning">статье в википедии на эту тему</a> .</p>

<p>major.minor.bugs</p><p>(или какой-то вариант)</p><p>ошибки - это, как правило, исправления ошибок без новой функциональности.</p><p>незначительные изменения - это добавление новых функциональных возможностей, но это никак не меняет программу.</p><p>major - это изменение в программе, которое либо ломает старую функциональность, либо настолько велико, что каким-то образом меняет способ использования программы пользователями.</p>

<p>каждый выбирает, что он хочет делать с этими числами. я испытывал желание называть релизы a.b.c, так как это все равно довольно глупо. при этом то, что я видел за последние 25 с лишним лет разработки, имеет тенденцию работать таким образом. допустим, номер вашей версии 1.2.3.</p><p>«1» обозначает «основную» ревизию. обычно это первоначальный выпуск, большое изменение набора функций или переписывание значительных частей кода. как только набор функций определен и хотя бы частично реализован, вы переходите к следующему номеру.</p><p>«2» указывает на выпуск в серии. часто мы используем эту позицию, чтобы освоить функции, которые не были реализованы в последнем основном выпуске. эта позиция (2) почти всегда указывает на добавление функции, обычно с исправлениями ошибок.</p><p>«3» в большинстве магазинов указывает на выпуск патча/исправление ошибки. почти никогда, по крайней мере, с коммерческой стороны, это не указывает на существенное добавление функции. если функции появляются в позиции 3, то это, вероятно, потому, что кто-то проверил что-то, прежде чем мы знали, что мы должны выпустить исправление ошибки.</p><p>за позицией «3»? я понятия не имею, почему люди делают такие вещи, это только запутывает.</p><p>особенно некоторые из oss там выбрасывают все это из безумия. например, версия 10 trac на самом деле 0.10.x.x. я думаю, что многим людям в мире oss либо не хватает уверенности, либо они просто не хотят объявлять о том, что они сделали основной релиз.</p>

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

<p>я думаю, что парадигма основного исправления release.minor release.bug довольно распространена. </p><p>в некоторых контрактах на поддержку предприятий есть $$$ (или нарушение обязательств по контракту), связанные с тем, как обозначен конкретный выпуск. например, контракт может дать клиенту право на некоторое количество основных выпусков за определенный период времени или пообещать, что в течение определенного периода будет меньшее количество x небольших выпусков или что поддержка будет по-прежнему доступна для стольких релизы. конечно, независимо от того, сколько слов вставлено в контракт, чтобы объяснить, что является основным выпуском по сравнению с второстепенным выпуском, оно всегда субъективно и всегда будут серые области, что приводит к возможности того, что поставщик программного обеспечения сможет настроить систему на бить такие договорные положения.</p>

<p>в случае с библиотекой номер версии говорит вам о <strong>уровне совместимости</strong> между двумя выпусками и, следовательно, о том, насколько сложным будет обновление.</p><p>выпуск исправления ошибки должен сохранить совместимость двоичного кода, исходного кода и сериализации.</p><p>незначительные релизы означают разные вещи для разных проектов, но обычно им не нужно сохранять совместимость с исходным кодом.</p><p>основные номера версий могут разбить все три формы.</p><p>я написал больше об обосновании <a href="http://motlin.com/2010/how-to-do-version-numbers/">здесь</a> .</p>

<p>major.minor.point.build обычно. основные и второстепенные говорят сами за себя, точка - это релиз для нескольких незначительных исправлений, а сборка - это просто идентификатор сборки.</p>

<p>обычно это:</p><p>majorversion.minorversion.revision.build</p>

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

<p>первый номер обычно называют основным номером версии. он в основном используется для обозначения значительных изменений между сборками (т.е. когда вы добавляете много новых функций, вы увеличиваете основную версию). компоненты с различными основными версиями одного и того же продукта, вероятно, несовместимы.</p><p>следующий номер - младший номер версии. он может представлять некоторые новые функции или ряд исправлений ошибок или небольших изменений архитектуры. компоненты из одного и того же продукта, которые отличаются по второстепенному номеру версии, могут или не могут работать вместе и, вероятно, не должны.</p><p>следующий обычно называется номером сборки. это может увеличиваться ежедневно, или с каждой «выпущенной» сборкой, или с каждой сборкой вообще. между двумя компонентами могут быть только небольшие различия, которые отличаются только номером сборки и обычно могут хорошо работать вместе.</p><p>конечным номером обычно является номер редакции. часто это используется автоматическим процессом сборки или когда вы делаете одноразовые одноразовые сборки для тестирования.</p><p>когда вы увеличиваете свои номера версий, зависит только от вас, но они всегда должны<em> увеличивать </em>или<em> оставаться неизменными </em>. можно разрешить всем компонентам использовать один и тот же номер версии или увеличить номер версии только на измененных компонентах.</p>

<p>номер версии сложного программного обеспечения представляет весь пакет и не зависит от номеров версий компонентов. версия gizmo 3.2.5 может содержать версию 1.2.0 foo и версию 9.5.4 bar.</p><p>при создании номеров версий используйте их следующим образом:</p><ol> <li><p>первый номер - главный выпуск. если вы вносите значительные изменения в пользовательский интерфейс или вам нужно сломать существующие интерфейсы (чтобы ваши пользователи должны были изменить свой интерфейсный код), вам следует перейти на новую основную версию. </p></li> <li><p>второе число должно указывать, что новые функции были добавлены или что-то внутренне работает иначе. (например, база данных oracle может решить использовать другую стратегию для извлечения данных, делая большинство вещей быстрее, а некоторые медленнее.) существующие интерфейсы должны продолжать работать, а пользовательский интерфейс должен быть узнаваемым. </p></li> <li><p>далее нумерация версий зависит от того, кто пишет программное обеспечение - oracle использует пять (!) групп, т.е. версия oracle это что-то вроде 10.1.3.0.5. начиная с третьей группы, вы должны вносить только исправления или незначительные изменения в функциональности. </p></li> </ol>

<p> <a href="http://www.indiangeek.net/2007/05/06/notes-on-the-software-build-process/">примечания по процессу сборки программного обеспечения</a> </p>

<p>те, которые меняются меньше, будут первыми двумя для major.minor, после этого это может быть что угодно от сборки, ревизии, релиза до любых пользовательских алгоритмов (как в некоторых продуктах ms)</p>

<p>вот что мы используем:</p><ol> <li>первый номер = общая система эпохи. изменения каждые пару лет и, как правило, представляют собой фундаментальные изменения в технологии, клиентских функциях или в обеих.</li> <li>второе число = версия схемы базы данных. увеличение этого числа требует переноса базы данных, что также является значительным изменением (или репликация систем и, следовательно, изменение структуры базы данных требует тщательного процесса обновления). сбрасывается на 0, если меняется первое число.</li> <li>третий номер = только программное обеспечение обычно это может быть реализовано на клиенте, так как схема базы данных не изменяется. сбрасывается на ноль при изменении второго числа.</li> <li>номер версии subversion. мы заполняем это автоматически при сборке с помощью инструмента tortoisesvn. это число никогда не сбрасывается, а постоянно увеличивается. используя это, мы всегда можем воссоздать любую версию.</li> </ol><p>эта система служит нам хорошо, потому что каждый номер имеет четкую и важную функцию. я видел, как другие команды боролись с вопросом о мажорном/минорном номере (насколько велико изменение), и я не вижу выгоды для этого. если вам не нужно отслеживать изменения в базе данных, просто перейдите на трехзначный номер версии и сделайте жизнь проще!</p>

<p>в версии v1.9.0.1: <strong>это явная схема управления версиями</strong>, используемая, когда вы не хотите использовать имя для предварительных выпусков или сборку, например -alpha, -beta.</p><p>1: основная версия, которая может нарушить обратную совместимость</p><p>9: добавление новых функций для поддержки вашего приложения вместе с обратной совместимостью с предыдущей версией.</p><p>0: некоторые мелкие исправления</p><p>1: номер сборки (номер предварительной версии)</p><p>но в настоящее время вы не найдете такой схемы управления версиями. см. семантическое управление версиями [semver2.0] <a href="https://semver.org/">https://semver.org/</a> </p>

<p>каждая организация/группа имеет свой собственный стандарт. важно то, что вы придерживаетесь любой выбранной вами системы обозначений, иначе ваши клиенты будут сбиты с толку. сказав, что я обычно использовал 3 номера:</p><p>x.yz.bbbbb. где: x: основная версия (основные новые функции) y: вспомогательный номер версии (небольшие новые функции, небольшие улучшения без изменений пользовательского интерфейса) z: пакет обновления (в основном тот же) как xy, но с некоторыми исправлениями ошибок bbbb: это номер сборки, который действительно виден только из «about box» с другими подробностями для поддержки клиентов.</p>

<p>сочетание основных, второстепенных, исправлений, сборок, исправлений безопасности и т.д.</p><p>первые два являются основными и второстепенными - остальные будут зависеть от проекта, компании и иногда сообщества. в таких ос, как freebsd, у вас будет 1.9.0.1\_number для представления исправления безопасности.</p>

<p>немного зависит от языка, например, delphi и c # имеют разные значения.</p><p>обычно первые два числа соответствуют основной и вспомогательной версии, т. е. 1.0 для первого реального выпуска, 1.1 для некоторых важных исправлений и второстепенных новых функций, 2.0 для большой новой версии.</p><p>третье число может относиться к «действительно второстепенной» версии или ревизии. например, 1.0.1 - это очень маленькое исправление для 1.0.0. но он также может содержать номер ревизии из вашей системы управления версиями или постоянно увеличивающийся номер, который увеличивается с каждой сборкой. или datestamp.</p><p>чуть более подробно <a href="https://stackoverflow.com/questions/650/automatically-update-version-number#706">здесь</a> . «официально», в .net 4 числа - «major.minor.build.revision», а в delphi - «major.minor.release.build». я использую «major.minor.reallyminor.subversionrev» для управления версиями.</p>

<p>обычно число указывается в формате version.major.minor.hotfix, а не в отдельных внутренних компонентах. таким образом, v1.9.0.1 будет версия 1, основной выпуск 9 (v1), вспомогательный выпуск (v1.9) 0, оперативное исправление 1 (v1.9.0).</p>