Синхронизировать числа во многих инструментах или нет?

Question

В настоящее время у нас есть много офисных продуктов и встроенных продуктов. Все они имеют одинаковую схему версий major . minor . номер сборки . svn revision . С ночными и ручными сборками, увеличивающими номер сборки.

С точки зрения поддержки разработки это действительно упрощает управление «правильной версией», но ребята из службы поддержки на месте паникуют, когда один инструмент переключается с v10 на v200, и мы говорим, что никаких изменений нет.

Есть ли какие-либо проблемы с этой схемой (все синхронизированы), которые мы упускаем из-за нашей любви к ней?

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

svn revision одинаков для всех файлов в момент времени x, но никто действительно не обращает на это внимание.

Все файлы .exe и .dll и т. Д. Имеют одинаковый номер X.Y.W.Z. Итак, офисный продукт переходит с 1.1.10.1234 на 1.1.132.4321, когда мы много работаем над встроенным продуктом.

Answer 1

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

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

Единственное предложение, которое я могу сделать, - это перейти на устаревший номер версии, чтобы основная и дополнительная версии не менялись так быстро. Что-то вроде 9.0417.yyyy.xxxx будет 17 апреля 2009 года с номером сборки yyyy и xxxx в качестве svn-ревизии. Если вы не хотите менять основной номер и хотите сохранить дату в младшем, вы можете использовать стиль управления версиями Microsoft. Есть хорошая статья в блоге о том, как Microsoft делает свои версии на http://blogs.msdn.com/jensenh/archive/2005/11/11/491779.aspx.

Answer 2

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

Таким образом, в агрегированной схеме СИСТЕМА имеет один большой номер версии, и каждая подсистема имеет свою собственную. Я использую нотацию в чистом виде, потому что я не знаю терминологию для equivelant в svn: компонент верхнего уровня содержит все подкомпоненты в иерархии (представьте, что компонент подобен папке с кодом в нем, так что все в эта папка имеет ту же версию, или «базовую линию», как ее называет clearcase).

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

Мы используем базовую дату-время и «номер выпуска» для версии системы верхнего уровня. Затем, каждая подсистема имеет основной / вспомогательный / build / svn. Кроме того, мы не показываем svn и номер сборки в "about-> help" или equivelant, только если вы углубитесь в какой-то файл "system config", вы можете извлечь фактический номер build / svn (например, посмотрев в метаданных в исполнении). Таким образом, пользователи видят только основную / вспомогательную версию, а не просто набор номеров сборок и номеров SVN.