Плюсы и минусы разных версий схем

Question

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

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

Вопросы, связанные с этим

Выбор номера версии
Как использовать номера версии?
Как узнать, какой номер версии использовать?
Какой предпочитаемый стиль номера версии продукта и почему? (это отвечает на мой второй вопрос)
Руководство по стилю управления версиями
Семантическое управление версиями (это, вероятно, лучшая схема управления версиями для компонентов, не уверенная в приложениях для конечных пользователей)

Подсказки

Это список подсказок, которые я нашел наИнтернет:

• Используйте как минимум трехчастную версию numbers (2.9.0, 2.10.0), поэтому очевидно, что они не являются десятичными.
• Используйте основанную на дате / времени версиюg ( source )
• Методдля извлечения времени компиляции из схемы автоматической версии .NET
• Автоматическое управление версиями с использованием MSBuild.Community.Tasks

Answer 1

MISV-программы могут характеризоваться высокой скоростью выпуска и, по крайней мере, высокой скоростью сборки (до нескольких сборок в день).

В этом контексте может быть интересно отслеживать:

• идентификатор сборки (который может быть идентификатором SVN или Git или Mercurial SHA1)
• классический Major.Minor. Версия сборки

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

Answer 2

Честно говоря, я думаю, что этот вопрос решен. Используйте метки даты и времени. Затем номера версий превращаются в читаемые строки, понятные людям.

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

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

Вот и все.