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

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

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

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

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

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

PatchNumber.DateMonthYear

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

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

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

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

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

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

До 1.0:

• 0.0.1 = Первый выпуск
• 0 .-. X = обратно совместимое обновление
• 0.X.0 = обратно несовместимое обновление

После 1.0:

• -.-. X = Обновление без изменений интерфейса
• -.X.0 = Обновление с дополнениями обратно совместимого интерфейса
• X.0.0 = обратно несовместимое обновление

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

Major.minor.patch.build причем патч является исправлением или выпуском патча.

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

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

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

• легче проверить требования к версии: если (версия <8.0901)умереть / выйти / и т. д.;
• он может быть автоматически сгенерирован в процессе сборки

По этой второй точке (рубин и рейк):

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

Major.Minor.BugFix.SVNRevision

например: 3.5.2.31578

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

В 80-х мне нравился способ создания версий компилятора Clipper в Нантакете:

Машинка для стрижки зимняя 1984
Клипер Лето 1985
Машинка для стрижки зимних 1985
Машинка для стрижки осень 1986
Клипер, лето 1987

Ну и накладки ....

[слезы на глазах]