Как Вы знаете что номер версии использовать?

Jeff Atwood имеет сообщение в блоге об этом, где он рекомендует просто использовать даты а не путать пользователя с номерами версий. Однако он действительно обсуждает подход, который проявила Microsoft: Используя даты для определения номеров версий. Он входит в довольно мало глубины в своем сообщении, таким образом, я не копирую его работу здесь. Что касается Управления версиями:

Версии (по крайней мере, в.NET, пройдите примерно так):

1.2.3.4, где:

1 , главная версия
2 , незначительный выпуск
3 сборка , номер
4 пересмотр , Главная версия номер

- Показывает 'полную' систему с любыми функциями, которые версия была предназначена для имения. Обычно любые последующие 'главные' версии являются перезаписями или изменениями архитектуры, или (извините дублирование), существенные изменения к программному обеспечению.

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

Номер сборки - Обычно показывает просто исправления ошибок, маленькие меры, и несколько незначителен в их объеме. Это могло быть что-то столь же простое как изменение контраста между передним планом и фоном приложения. Обычно Сборки являются внутренними обозначениями, такими как ночные сборки, таким образом, у Вас всегда есть место для возвращения назад к этому, стабильно.

Пересмотр Номер - показывает, когда исправления ошибок выпущены, или ОЧЕНЬ незначительные улучшения сделаны. Они обычно резервируются для просто исправлений ошибок - , не включают улучшения основной функции как изменения .

Мы присваиваем каждую сборку любого приложения уникальные четыре номера версии части, определенные как Главный. Незначительный. Обслуживание. Сборка .

Главный - Главное число связано с существенными изменениями к приложению. Это число также определяет совместимость с другими приложениями в том же "комплекте". Это число увеличено, когда новые выпуски сделаны. Это обычно означает, что основные изменения в архитектуре произошли.

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

Обслуживание - число Обслуживания связано с неразрывными исправлениями ошибок. Это число будет усовершенствовано каждый раз, когда выпуск сделан, который содержит только исправления ошибок неповреждения.

Сборка - Номер сборки связан с подрывной деятельностью changeset (число пересмотра) , от которого было скомпилировано приложение. Это обеспечит простой способ соответствовать номеру версии к точному набору кода в подрывной деятельности.

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

Я думаю, что ядро 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, нет никакого значения для четных или нечетных чисел с разработкой новой возможности, продолжающейся в том же ряду ядра. Linus Torvalds заявил, что это будет моделью для обозримого будущего.

* 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's код NFS. Однако было недостаточно других изменений для узаконивания выпуска нового незначительного пересмотра (который будет 2.6.9). Так, 2.6.8.1 был выпущен, с единственным изменением, являющимся фиксацией той ошибки. С 2.6.11, это было принято как новая официальная политика управления версиями. Исправлениями ошибок и патчами безопасности теперь управляет четвертое число, тогда как большие изменения только реализованы в незначительных изменениях пересмотра (число C). Число D также связано с количеством раз, что компилятор создал ядро, и таким образом назван "номером сборки".

кроме того, иногда после того, как версия там будет еще некоторыми буквами, такими как 'rc1' или 'mm2'. 'Дистанционное управление' относится к предвыпускной версии и указывает на неофициальный выпуск. Другие буквы обычно являются (но не всегда) инициалами человека. Это указывает на ответвление разработки ядра тем человеком. например, ck поддерживает Con Kolivas, ac поддерживает Alan Cox, тогда как мм, выдержанное за Andrew Morton. Иногда, буквы связаны с основной областью разработки ответвления, ядро создается из, например, wl указывает на тестовую сборку беспроводных сетей.

От http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering

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

Вне совместимости, я также думаю, что существует много, чтобы быть сказанным для использования дат. Хотя становится неловким, если, как я, Ваш план выпуска один раз в два года (но это для инструмента, сначала выпущенного в 1989).

Для добавления ко всему объяснению выше я предложу, используют схему управления версиями, которую, будет легко для клиентов помнить и легкий для Вас к базовой линии и управлять Вашими версиями программного обеспечения. Кроме того, при поддержке различной платформы, такой как.Net 1.0.Net1.1 и т.д., затем удостоверьтесь, что схема управления версиями заботится об этом также.

Более, чем вероятный кто-то в продажах или маркетинге решит, что им нужен некоторый шум. Это определит, ли следующий выпуск 1.01 или 1.1 или 2.0. Вид работ то же в открытом исходном коде, но это склоняется к связанному с необычной новой возможностью, которой команда гордится.

A.B.C.D

• А: 0, когда бета, 1, когда сначала выпускают, больше тогда 1 почти на всей перезаписи.
• B: Новые возможности добавили
• C: Исправления ошибок сделаны
• количество пересмотра репозитория управления версиями

некоторая хорошая информация здесь также..

, Когда Изменить Версии Файла/Блока

, Когда Изменить Версии Файла/Блока, В первую очередь, версии файла и версии блока не должны совпадать друг с другом. Я рекомендую, чтобы версии файла изменились с каждой сборкой. Но, don’t изменяют версии блока с каждой сборкой именно так, что можно сказать различие между двумя версиями того же файла; используйте версию файла для этого. Решение, когда изменить версии блока, берет некоторое обсуждение типов сборок для рассмотрения: поставка и непоставка.

Непоставлющиеся Сборки В целом, я рекомендую продолжать не поставляться, блок присваивает версию тому же между поставкой сборок. Это избегает проблем загрузки сборки со строгим именем из-за несоответствий версии. Некоторые люди предпочитают использовать политику издателя перенаправить новые версии блока для каждой сборки. Я рекомендую против который для непоставки сборок, однако: это doesn’t избегает всех загружающихся проблем. Например, если партнер копирует Ваше приложение с помощью xcopy, они не могут знать для установки политики издателя. Затем Ваше приложение будет повреждено для них, даже при том, что оно работает просто великолепно на Вашей машине.

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

Поставлющиеся Сборки Что касается того, зависит ли it’s хорошая идея изменить ту версию для поставки сборок, это от того, как Вы хотите, чтобы привязка работала на конечных пользователей. Вы хотите, чтобы эти сборки были бок о бок или оперативные? Есть ли между двумя сборками много изменений? Они собираются повредить некоторых клиентов? Вы заботитесь, что это повреждает их (или Вы хотите вынудить пользователей использовать Ваши важные обновления)? Если да, необходимо рассмотреть постепенное увеличение версии блока. Но с другой стороны полагайте, что выполнение, который слишком много раз может замусорить user’s диск устаревшими блоками.

, Когда Вы Изменяете Свои Версии блока Для изменения hardcoded версий на новую, я рекомендую установить переменную на версию в заголовочном файле и заменить жесткое кодирование в источниках с переменной. Затем выполните препроцессор во время сборки, чтобы вставить правильную версию. Я рекомендую изменить версии прямо после поставки, не прямо прежде, так, чтобы там был пора больше поймать ошибки из-за изменения.

Это - то, что я использую для модулей во встроенных проектах C:

1.00 - Первоначальная версия

1.01 - Незначительный пересмотр
изменения интерфейса No в модуле (т.е. заголовочный файл не изменился). Кто-либо использующий мой модуль может обновить, не имея необходимость бояться повреждающегося кода. Я, возможно, сделал некоторый рефакторинг или очистку кода.

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

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