Нужна помощь со схемами номеров версий - PullRequest
3 голосов
/ 26 мая 2010

Я знаю стандарт Major.Minor.Build.Revision, но есть несколько соображений, которые для нас несколько уникальны

-Мы делаем внутренние выпуски почти ежедневно, иногда чаще, чем один раз в день.

- Установщик Windows не проверяет версию , так что это почти спорный вопрос для наших целей.

- Основные и второстепенные номера в идеале обновляются только для публичных выпусков и должны выполняться вручную.

- Это оставляет Build #, который должен быть автоматически обновлен.

- Мы хотим, чтобы внутренние выпуски можно было выполнять с любого компьютера разработчика, чтобы исключить использование xx * в Visual Studio, поскольку на разных компьютерах могут генерироваться разные числа, и каждая сборка не обязательно будет больше, чем предыдущая ,

- У нас около 15 или около того проектов в составе продукта, поэтому сохранение номеров версий в SVN не является идеальным, так как в каждом выпуске мы будем фиксировать все эти файлы.

Учитывая эти критерии, я не могу придумать хорошую схему управления версиями. Последние 2 критерия могут быть отброшены, но удовлетворение всех этих требований кажется идеальным. Штамп с датой недостаточен, потому что мы можем делать больше одного в день, и учитывая максимальный размер Uint16 (около 64000) (на самом деле, используя WiX, он жалуется на числа выше Int16.MaxValue), дата / время не подходят.

Ответы [ 2 ]

3 голосов
/ 26 мая 2010
  1. Используйте SVN номера коммитов или другие идентификаторы коммитов (обычно мы используем git describe вывод, что идеально в большинстве случаев). Сборки должны быть прослеживаемыми - важно собирать их только из подтвержденных источников, если вы действительно хотите определить, что у вас работает.
  2. Используйте время / дату с точностью до секунды (время эпохи UNIX). Это будет работать для вас до 2038 года. Если число слишком велико, используйте другую эпоху (например, 2000 год).

Кроме того, Uint32 не ограничен 2 ^ 16 (65535), его 32-битный дает вам 2 ^ 32 или примерно 4 млрд.

2 голосов
/ 29 мая 2010

Поскольку msi не проверяет ревизии, мы переключили третью и четвертую часть версии в нашей системе сборки на msi.

Например, если реальная версия - 1.2.3.4678 (4678 - это SVNревизия, из которой построено приложение), мы создаем версию msi как 1.2.4678.3.

...