Как вы реализуете свои проекты?

Я понимаю, что Microsoft использует этот шаблон при версировании своих продуктов: Major.Minor.Build.Revision.

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

Незначительное число представляет собой значительное улучшение с целью обратной совместимости.

Номер сборки - небольшое изменение, например перекомпиляция того же источника.

Редакция используется для исправления дыры в безопасности и должна быть полностью взаимозаменяемой. Как Build, так и Revision являются необязательными. Эта информация основана на классе версии MSDN.

Как вы оцениваете свои проекты и почему вы их версии таким образом?

Ответ 1

Обычно мы выполняем major.minor [.maintenance [.build]], где я работаю, но, похоже, он немного отличается от каждого проекта.

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

Ответ 2

Смотрите следующее: Вопрос номер версии SO

Ответ 3

Мне лично нравится использовать схему, которая фокусируется на уровне обратной совместимости, которую могут ожидать пользователи проекта/продукта:

До 1.0:

0.0.1 = Первая версия
0.-. X = Обратная совместимость обновления
0.X.0 = Непротиворечивое обновление назад

После 1.0:

-.-. X = Обновление без изменений интерфейса
-. X.0 = Обновление с добавлением обратных совместимых интерфейсов
X.0.0 = Обратное несовместимое обновление

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

Ответ 4

Я часто вижу Xyz, где X - год после номера выпуска, а yz - месяц года. То есть 201 - через 2 года после выпуска. То есть когда продукт запускается в мае, его первый номер выпуска - 105. Релиз в феврале следующего года - 202.

Ответ 5

Обычно мы разрабатываем наши проекты на основе текущей даты выпуска, YYYY.MM.DD. *, и мы даем номер сборки генерироваться автоматически, так, например, если бы у нас была версия сегодня, это было бы 2008.9.26.BUILD.

Ответ 6

Я использую major.minor.point.revision, где point является выпуском только для исправления ошибок, а ревизия - это ревизия репозитория. Это легко и хорошо работает.

Ответ 7

Я просто делаю Major.minor. Поскольку я - один разработчик (со случайной помощью), работающий над веб-приложением, большинству людей было все равно, о незначительных исправлениях, которые я делаю. Поэтому я просто пересматриваю второстепенные версии, когда добавляю новые функции и номера основных версий, когда я делаю некоторые изменения или обновления. В противном случае, я просто игнорирую небольшие исправления по мере того, как номера версий идут (хотя у меня есть номера ревизий Subversion, если мне нужно вернуться для себя).

Ответ 8

Я работаю над большим количеством небольших проектов, и я лично нашел это полезным.

PatchNumber.DateMonthYear

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

PatchNumber - это количество выпущенных релизов, а остальное используется для показа пользователей при публикации.

Ответ 9

Major.minor.patch.build с исправлением исправления или исправления.

Если вы можете получить QA на дюйм и на SVN, вы можете использовать ревизию svn HEAD как номер сборки. Таким образом, каждая сборка описывает, откуда она взялась, с точки зрения контроля источника и того, что в сборке. Это означает, что у вас будут сборки, которые растут с пробелами (1.0.0.1, 1.0.0.34....)

Ответ 10

Major.Minor.BugFix.SVNRevision

например: 3.5.2.31578

SVN Revision дает вам очень точный код кода, отправленный клиенту. Вы абсолютно уверены, что это исправление было или нет.
Это также помогает найти правильный PDB в случае, если у вас есть ошибка приложения. Просто совместите SVN Revisions на своем сервере сборки, скопируйте PDB в EXE-местоположение, откройте отладчик и получите трассировку стека аварий.

Ответ 11

У меня просто есть номер. Первый выпуск 001. Третья бета-версия второго релиза 002b3 и так далее. Это просто для личного ума, у меня на самом деле нет ничего "выпущенного" на данный момент, так что это вся теория.

Ответ 12

Я начал использовать псевдоподобный формат Ubuntu: Y.MMDD

Это помогает по нескольким причинам:

легче проверить требования к версии: if (version < 8.0901) die/exit/etc. ;
он может быть автоматически сгенерирован в процессе сборки

В этой 2-й точке (рубин и грабли):

def serial(t)
   t = Time.now.utc if not t.instance_of?(Time)
   t.strftime("%Y").to_i - 2000 + t.strftime("0.%m%d").to_f
end

serial(Time.now)     #=> 8.0926
serial(Time.now.utc) #=> 8.0927

ПРИМЕЧАНИЕ: t.strftime( "% Y.% m% d" ). to_f - 2000 работает с неточностями с плавающей запятой: 8.09269999999992

Ответ 13

Мне нравился способ Nantucket по версии своего компилятора Clipper в 80-е годы:

Клипер Зима 1984
Клипер Лето 1985
Clipper Winter 1985
Клипер Осень 1986
Clipper Summer 1987

Oh и наложения....

[становится слезливым]