Предположим, у меня есть веб-приложение с некоторыми базовыми функциями. Я хочу продать его. Поэтому я хотел бы присвоить номер версии - что-то вроде 0.0.1. Я хочу знать, есть ли какие-либо ограничения, которые должны применяться к этой системе нумерации?
Надеюсь, ты понял мой вопрос, спасибо заранее.
В большинстве мест используется что-то вроде этого:
Основная версия Release.Minor Release.Hot Fix.Build
Ваши номера версий выглядят как 1.5.0.15 и т.д.
В большом количестве бесплатного программного обеспечения используется трехточечная система: X.Y.Z где
Таким образом, версия 0.28.1 - это стабильная версия с одним исправлением, а 2.9.0 - это альфа-релиз с нулевыми исправлениями.
Некоторые люди также получают удовольствие от разработки своих собственных схем. Например. Tex, который по каждому выпуску приближался к Pi, с номерами версий: 3, 3.1, 3.14 и т.д.
Это не имеет большого значения, если вы можете использовать номер версии для идентификации своих версий (например, добавить внутренний номер ревизии системы управления версиями в номер версии) или использовать его для пометки своих выпусков.
Когда вы это сделаете, вы можете использовать этот номер в качестве третьего (или четвертого) компонента. Это выглядит запутанным, если какой-то продукт перескакивает с версии 1.12345 на 2.12346, но более часто встречается переход от 1.4.12345 до 2.0.12345.
О том, какой номер начать, я просто хочу процитировать Eric S. Raymond:
В мире с закрытым исходным кодом Version 1.0 означает "Не прикасайтесь к этому, если вы сообразительны"; в мире с открытым исходным кодом он читает нечто более похожее на разработчики готовы репутации на этом. "
Вы можете использовать любые номера, которые вы хотите в своем управлении версиями, - кто собирается вас сдерживать?
Если вы хотите, чтобы ваша первая версия была 0.0.0.0.0.0.0.1, это прекрасно, хотя и немного глупо. Если вы хотите, чтобы ваша первая версия была 106,3, вы тоже можете это сделать, но это немного более смешно.
Просмотрите статью Википедии о версии программного обеспечения для некоторых проверенных идей реалистичных схем нумерации версий.
Я всегда использовал (переписываю). (добавлена функция). (исправление ошибки).
Но настройте свои собственные правила и сделайте их общедоступными, чтобы ваши пользователи поняли их.
Посмотрите здесь. У python setuptools есть очень интересная и ясная спецификация для нумерации версий. Я уверен, что вы можете получить от него очень проницательные намеки.
Насколько мне известно, до сих пор ни одно правительственное агентство не диктует, как вы числяете версии. Но не беспокойтесь, я уверен, что скоро это произойдет.
То же самое можно сказать о тех, которые предполагают пересмотр мажоритарной домены. Мой общий подход: основные изменения получают новую крупную версию. Например, если мы добавили важные новые функции. Небольшие изменения, такие как добавленные некоторые небольшие удобства или один новый отчет, получают небольшую ревизию. Изменения в исправлении с горячей ошибкой получают ревизию.
Я бы определенно не позвонил в вашу первую опубликованную версию "0.1" по простым маркетинговым соображениям: цифры менее 1.0 звучат как предварительная версия или бета-версия. Я знал, что люди называют свою первую версию 2.3 или некоторые из них просто для того, чтобы это звучало, как будто было немного, чтобы внушить больше уверенности, хотя это кажется мне немного нечестным.
как о программном обеспечении, которое не распространяется на общественность, как исходный код веб-почты? вы считаете, что число исправлений сборки или ошибки по-прежнему важно в этом случае?
Вы можете начать с просмотра статьи Software versioning о википедии, которая дает некоторую информацию о ваших возможностях; -)
Это может дать вам некоторые идеи о том, что вы могли бы сделать в своем конкретном случае...
Я использовал
Major.Minor.Release.Build 1.02.4.15
а также
Year.Month.Date
2009.12.10
но все, что позволяет вам индивидуально отслеживать релизы, будет работать. Пока вы согласны.
Мы используем major.minor.revision.build, где ревизия - это ревизия SVN, а build - это номер сборки, основанный на текущей дате (в формате YYDDD, где YY - год, а DDD - номер дня, поэтому 18001 будет 1 января 2018 года.)
Проверка SVN невероятно полезна и спасла нас не один раз.
Номера версий не являются конкретной спецификацией в разработке программного обеспечения.
Другими словами, одна команда может использовать 1.0.0.0, другие могут использовать 1.0.0 и так далее. Это не важно.
Просто выберите то, что работает для вас.
Обычно major.minor.revision является самым простым и прямым способом использования. Visual Studio, например, может автоматически назначать номера версий для вас, а также другие инструменты. Таким образом, все, что вам необходимо обновить, - это основные/второстепенные значения. Номера сборки/ревизии обновляются автоматически.
Кажется, я помню, что в старые времена (я говорю Commodore здесь) мы использовали синтаксис вроде release.version.revision который может быть добавлен с помощью исправления и/или сборки, где исправление обычно представляет собой письмо, прикрепленное непосредственно к ревизии. Таким образом, полный номер читал бы что-то вроде:
2.1.44a.786
Но, как уже было сказано, это не имеет большого значения, для этого нет истинного стандарта. Просто используйте то, что наиболее удобно для вас.
Прочитав много статей /QAs/FAQs/books, я стал думать что [MAJOR]. [MINOR]. [REV] - самая полезная схема управления версиями для описать совместимость между версией проекта (схема управления версиями для разработчика, не для маркетинга).
ОСНОВНЫЕ изменения отстают в несовместимости и требуют изменения имя проекта, путь к файлам, идентификаторы GUID и т.д.
Изменения MINOR совместимы с обратными. Отметить введение новых особенности.
REV для исправлений безопасности/ошибок. Совместимость с обратной связью.
Эта схема управления версиями, основанная на семантике версий версий libtool и статьях:
http://www106.pair.com/rhp/parallel.html
ПРИМЕЧАНИЕ. Я также рекомендую предоставить build/date/custom/quality дополнительную информацию (build номер, дата сборки, имя клиента, качество выпуска):
Приветственное приложение v2.6.34 для Национального банка, 2011-05-03, betastrong > , build 23545
Но эта информация - это не информация о версии!!
10.50.1600.1
major.minor.build.revision
ОСНОВНЫЕ изменения отстают от несовместимости и требуют изменения имени проекта, пути к файлам, идентификаторов GUID и т.д.
Изменения MINOR обратно совместимы. Пометить введение новых функций.
REV для исправлений безопасности/ошибок. Совместимость с обратной связью.
например. В версии SQL Server 2008 RTM версии 10.00.1600.22, а в версии SQL Server версии 11.00.2100.60
Первое поле изменяется из-за изменения названия проекта, т.е. 10 и 11
В SQL Server 2008 R2 номер версии RTM - 10.50.1600.1, а в версии SQL Server 2008 - 11.00.1600.22
Второе поле изменяется из-за введения новых функций.
Третье поле указывает на сборку (развитую)
Поле Forth указывает на исправление, то есть исправления...
Вы можете использовать любую нумерацию нужной версии.
Я просто рекомендую использовать что-то, что имеет смысл. Нумерация Major.Minor.Revision является популярной, но любая нумерационная схема, которую вы хотите, "действительна".
При разработке программных библиотек я рекомендую, используя номер версии, чтобы сообщить уровень совместимости источников и двоичных файлов между двумя версиями.
Поскольку вы разрабатываете веб-приложение, вероятно, достаточно двух версий версии. Первая часть - для новых функций, вторая - для исправлений.