Здесь я всегда задавался вопросом...
Пожалуйста, извините мою наивность, но... Как вы определяете, какой номер версии для названия вашего программного обеспечения?
Я предполагаю, что когда кто-то создает "окончательную" версию приложения/программы, это версия 1.0? - Затем, что происходит, когда вы его обновляете, как вы решаете назвать его 1.1 или 1.03 и т.д.
Это в основном для разработчика?
Недавно я услышал более серьезную стратегию управления версиями, с которой я впервые столкнулся в Eric Elliot Medium account. Он более взвешен по сравнению с версией библиотеки, которая имеет отношение к номерам версий, но имеет преимущество в простоте. Используйте номер версии из трех частей, где каждый номер означает:
breaking.feature.fix
Я оставляю свой старый ответ ниже, поскольку он все еще имеет отношение к версиям, стоящим на стороне клиента.
Я склоняюсь к весовым значащим цифрам следующим образом.
w.x.y.z(или w.xyz)
Если вы решите использовать формат w.xyz, вы получите только 9 цифр перед переполнением. Однако, если вы часто выпускаете это, у вас может возникнуть большая проблема.
Позвольте проиллюстрировать FooApp, мой новый продукт!
Jeff Atwood имеет сообщение в блоге об этом, где он выступает только за использование дат и не путает пользователя с номерами версий. Тем не менее, он действительно обсуждает подход Microsoft: Использование дат для определения номеров версий. Он занимает довольно много места в своем посте, поэтому я не буду дублировать его работу здесь. Что касается версии:
Версии (по крайней мере, в .NET, идите примерно так):
1.2.3.4 где:
1 является основным выпуском
2 - младший выпуск
3 - номер build
4 - версия
Основной релиз - обозначает "полную" систему с любыми функциями, которые должна была иметь эта версия. Обычно любые последующие "основные" версии являются перезаписыванием или изменениями архитектуры или (извините за избыточность) основными изменениями программного обеспечения.
Малый выпуск. Значит менее значимый выпуск, возможно, исправления ошибок, добавленные небольшие функции или любое количество других "второстепенных" событий. Это может включать изменения интерфейса и дополнения. Обычно приложения должны быть несколько совместимы в своем "основном выпуске", поэтому второстепенные версии одного и того же основного релиза должны быть архитектурно одинаковыми.
Номер сборки. Как правило, это просто исправления ошибок, небольшие исправления и несколько незначительны по своим масштабам. Это может быть что-то простое, как изменение контраста между передним и задним частями приложения. Как правило, Builds - это внутренние обозначения, такие как ночные сборки, поэтому у вас всегда есть место, чтобы вернуться к тому, что стабильно.
Номер редакции - означает, когда исправлены ошибки, или ОЧЕНЬ незначительные улучшения. Обычно они зарезервированы только для исправлений ошибок - не включают основные улучшения функций в качестве ревизий.
Мы назначаем каждую сборку любого уникального четырехчастичного номера приложения, определенного как Major.Minor.Maintenance.Build.
Основной - Основное число связано со значительными изменениями в приложении. Это число также определяет совместимость с другими приложениями в одном и том же "пакете". Это число увеличивается при создании новых выпусков. Обычно это означает, что произошли крупные архитектурные изменения.
Незначительный. Незначительное число связано с новой функциональностью и исправлением ошибок исправления. В любое время, когда вводится новая функциональность или когда применяется исправление ошибки исправления, это число будет расширено, а номер обслуживания будет установлен на ноль.
Техническое обслуживание. Номер технического обслуживания связан с исправлениями исправления ошибок. Это число будет доступно при каждом выпуске, который содержит исправления ошибок без прерывания.
Build. Номер сборки связан с набором изменений subversion (номер версии), из которого было скомпилировано приложение. Это обеспечит простой способ сопоставления номера версии с точным набором кода в подрывной деятельности.
Единственным номером, который разработчики действительно интересуют в этой схеме, является Построить. номер. Связывая номер Сборка с номером ревизии subversion, мы можем гарантировать, какой код использовался для создания выпущенного приложения.
Я думаю, что ядро Linux является хорошей ссылкой для этого:
Номер версии ядра Linux в настоящее время состоит из четырех номеров, после недавнего изменения давняя политика трехкратного схема управления версиями. Для иллюстрации, пусть предполагается, что версия число составлено таким образом: A.B.C [.D] (например, 2.2.1, 2.4.13 или 2.6.12.3).
* The A number denotes the kernel version. It is rarely changed, andтолько при существенных изменениях кода и возникает концепция ядра. Он был дважды изменен в история ядра: в 1994 году (версия 1.0) и в 1996 году (версия 2.0).
* The B number denotes the major revision of the kernel. o Prior to the Linux 2.6.x series, even numbers indicate a stableто есть тот, который считается подходящим для производства, например 1,2, 2,4 или 2.6. Нечетные числа исторически были выпуски разработки, такие как 1.1 или 2.5. Они были для тестирования новых функций и драйверов, пока они не стали достаточно стабильны для включения в стабильный выпуск. Это был четный/нечетный версия номер схема. o Начиная с серии Linux 2.6.x, нет никакого значения для четных или нечетных чисел, с новыми разработка функций в той же серии ядер. Линус Торвальдс заявил, что это будет модель для в обозримом будущем.
* The C number indicates the minor revision of the kernel. In the oldтрехмерная схема управления версиями, это был изменен, когда исправления безопасности, ошибка исправления, новые функции или драйверы были реализованный в ядре. С однако новая политика, однако, изменено, когда новые драйверы или функции введены; незначительные исправления обрабатывается номером D.
* A D number first occurred when a grave error, which required immediateвстречался в 2.6.8 NFS код. Однако их было недостаточно другие изменения, чтобы узаконить выпуск новой незначительной версии (которая было бы 2.6.9). Итак, 2.6.8.1 был выпущен с единственным изменением будучи исправлением этой ошибки. С 2.6.11, это было принято в качестве новой официальной политики в отношении версий. Исправление ошибок и исправления безопасности теперь управляются по четвертому числу, тогда как больше изменения осуществляются только в незначительных изменения версии (номер C). D номер также связан с количество раз, которое компилятор имеет построил ядро и, таким образом, называется "номер сборки".
Кроме того, иногда после версии там будет еще несколько писем таких как "rc1" или "mm2". "Rc" означает освободить кандидата и указать неофициальный выпуск. Другие письма обычно (но не всегда) инициалы человека. Это указывает на ветвь развития ядра тот человек. например ck означает Con Коливас, ак выступает Алан Кокс, тогда как мм стоял за Эндрю Мортоном. Иногда письма связаны с основная область разработки ветвь, из которой построено ядро, для Например, wl обозначает беспроводную сборка сетевых тестов.
От http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering
Независимо от того, какую схему нумерации вы выбираете, важно четко указать пользователям , когда новая версия совместима со старым кодом клиента и , когда новая версия требует изменений существующих клиентов. Большинство проектов, которые я знаю, имеют самый первый номер, когда клиентский код должен меняться.
Помимо совместимости, я тоже думаю, что много говорят о том, как использовать даты. Хотя это становится неловко, если, как и я, ваш график выпуска раз в два года (но это для инструмента, впервые выпущенного в 1989 году).
A.B.C.D
Это то, что я использую для модулей во встроенных проектах C:
1.00 - Начальная версия
1.01 - Малая ревизия
Никаких изменений интерфейса в модуле (т.е. Файл заголовка не изменился).
Любой, кто использует мой модуль, может обновиться, не опасаясь разрыва кода.
Возможно, я сделал некоторые рефакторинг или очистку кода.
2.00 - Основная ревизия
Изменен интерфейс модуля (т.е. Добавлены функции, удалены или функциональные возможности некоторых функций). Обновление до этой версии, скорее всего, нарушит существующий код и потребует рефакторинга кода с использованием этого модуля.
Я должен добавить, что это относится к стадии разработки, то есть к внутренним выпускам модулей в проект.
Чтобы добавить все объяснения, приведенные выше, я предлагаю использовать схему управления версиями, которая будет легко для ваших клиентов запоминать и легко вам ориентироваться и управлять версиями программного обеспечения. Кроме того, если вы поддерживаете различные структуры, такие как .Net 1.0,.Net1.1 и т.д., Убедитесь, что ваша схема управления версиями также заботится об этом.
Скорее всего, кто-то из продаж или маркетинга решит, что им нужно какое-то жужжание. Это определит, будет ли следующий выпуск 1,01 или 1,1 или 2,0. Вид работ одинаковый с открытым исходным кодом, но он имеет тенденцию привязываться к необычной новой функции, которой команда гордится.
какая-то хорошая информация здесь.
Когда менять файлы/версии сборки
Когда менять файлы/версии сборки Прежде всего, версии файлов и версии сборки не должны совпадать друг с другом. Я рекомендую, чтобы версии файлов изменялись с каждой сборкой. Но, не изменяйте версии сборки с каждой сборкой, чтобы вы могли отличить две версии одного и того же файла; используйте для этого версию файла. Решение о том, когда менять версии сборки, требует некоторого обсуждения типов сборок, которые необходимо учитывать: отгрузки и доставки.
Не поставляемые сборки В общем, я рекомендую сохранять версии сборки, не связанные с отправкой, одинаковыми между судоходными сборками. Это позволяет избежать проблем с загрузкой сборок, вызванных ошибками, из-за несоответствий версии. Некоторые люди предпочитают использовать политику издателя для перенаправления новых версий сборки для каждой сборки. Тем не менее, я рекомендую против этого для не-отгрузочных сборок: он не избегает всех проблем с загрузкой. Например, если партнер x-копирует ваше приложение, они могут не знать, устанавливать политику издателя. Тогда ваше приложение будет разбито для них, хотя оно отлично работает на вашей машине.
Но если есть случаи, когда разные приложения на одном компьютере должны связываться с различными версиями вашей сборки, я рекомендую предоставить эти сборки другим версиям сборки, чтобы можно было использовать правильный для каждого приложения без использования LoadFrom/др.
Доставка сборки Что касается того, хорошая ли идея изменить эту версию для сборки, она зависит от того, как вы хотите, чтобы привязка работала для конечных пользователей. Вы хотите, чтобы эти сборки были бок о бок или на месте? Много ли изменений между двумя сборками? Они собираются сломать некоторых клиентов? Вам небезразлично, что это нарушает их (или вы хотите заставить пользователей использовать важные обновления)? Если да, вам следует рассмотреть возможность увеличения версии сборки. Но, опять же, подумайте, что делать это слишком много раз может помешать диск пользователей устаревшими ассемблиями.
Когда вы меняете свои версии сборки Чтобы изменить жестко кодированные версии на новые, я рекомендую установить переменную в версию в файле заголовка и заменить хардкодирование в источниках переменной. Затем запустите предварительный процессор во время сборки, чтобы установить правильную версию. Я рекомендую менять версии сразу после отгрузки, а не сразу, чтобы было больше времени, чтобы поймать ошибки из-за изменения.
В случае библиотеки номер версии сообщает вам о уровне совместимости между двумя версиями и, следовательно, насколько сложно будет обновление.
Релиз исправления ошибок должен поддерживать совместимость с двоичным кодом, источником и сериализацией.
Малые релизы означают разные вещи для разных проектов, но обычно им не нужно сохранять совместимость с исходниками.
Основные номера версий могут разбивать все три формы.
Я написал больше об обосновании здесь.
Это зависит от проекта. ниже - политика управления версиями пакета haskell.
-- The package version. See the Haskell package versioning policy (PVP)
-- for standards guiding when and how versions should be incremented.
-- http://www.haskell.org/haskellwiki/Package_versioning_policy
-- PVP summary: +-+------- breaking API changes
-- | | +----- non-breaking API additions
-- | | | +--- code changes with no API change
version: 0.1.0.0