Ищем лучшие практики для нумерации версий зависимых программных компонентов

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

Давайте будем более конкретными:

Программный компонент A - это встроенное программное обеспечение, работающее на встроенном устройстве, а компонент B - его соответствующий драйвер для обычного ПК (компьютера с Linux / Windows). Они общаются друг с другом, используя собственный протокол. Поскольку наш продукт также предназначен для разработчиков, мы предложим стабильные и нестабильные (экспериментальные) версии обоих компонентов (прошивка с закрытым исходным кодом, а драйвер с открытым исходным кодом). Нашей самой большой трудностью является то, как обрабатывать изменения API в протоколе связи.

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

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

Итак, вот наше решение:

Мы планируем придерживаться широко используемой нумерации версий major.minor.patch и использовать четные / нечетные младшие номера для стабильных / нестабильных версий. Если мы внесем изменения в API, мы увеличим младший номер.

Это соглашение приведет к следующей примерной ситуации:

Текущая стабильная ветвь - 1.2.1, а нестабильная - 1.3.7. Теперь новый патч для нестабильной версии изменяет API, что приведет к тому, что номер новой нестабильной версии станет 1.5.0. Когда нестабильная ветка считается стабильной, скажем, в 1.5.3, мы выпустим ее как 1.4.0.

Я был бы рад ответить на любой из связанных вопросов ниже:

• Можете ли вы предложить лучшую практику для решения проблем, описанных выше?
• Как вы думаете, наша «обычай» конвенция хороша?
• Какие изменения вы бы применили к описанному соглашению?

ИМХО номера версий похожи на названия продуктов; важно то, что они видны, но неважно, что они являются украшением, а не содержанием.

Тем не менее, номер версии, как и название продукта, имеет значение. И самое главное, что вы можете сделать, это избежать путаницы. Итак, вот некоторые общие ожидания в отношении номеров версий. Если эти исключения не соблюдены, пользователь, вероятно, будет сбит с толку:

Номера версий монотонно растут.
Это, пожалуй, самое очевидное ожидание, и в то же время наименее вероятно, что оно действительно будет правдой. На первый взгляд, пользователь ожидает, что версия 2.3.5 будет выпущена после версии 2.2.17 и имеет ту же или лучшую технологию. Но, конечно, 2.3.x - это ветка разработки , и 2.2.x стабильна , а 2.3.5 фактически был выпущен еще в 2004 году, а ветка 2.2 все еще активно работает, а 2.2.17 была выпущена только в апреле прошлого года и содержит. .. ну, вы поняли. Вы могли бы также просто назвать версию 2.2 "Картошка" для всего значения, которое несет число. Добро пожаловать в версию " Картошка-17 " !!

Подобные версии могут быть обновлены / совместимы.
Если у меня на компьютере установлена ​​версия 3.7, а в 3.8 поставляются все новые блестящие фрозботы, я ожидаю, что с некоторыми обновлениями или патчами или чем-то другим мой 3.7 может стать 3.8 без перерыва. Но если я на 3.7, а вы выпускаете 5.2, я не такой оптимистичный. Конечно, я бы скорее был приятно удивлен, чем разочарован.

Первая цифра важна,
я бы даже не упомянул об этом, если бы Java не была настолько запутанной в этом вопросе. Если бы кто-то не сказал вам, вы бы не ожидали, что «Java 7» на самом деле была версия 1.7. И когда вы впервые услышали это, ваш ответ был почти наверняка: « Что? .. Почему? »

Ясно, что пурист скажет, что основной номер версии изменится только в том случае, если изменение платформы не будет обратно совместимым. Но вы на самом деле намерены отказаться от обратной совместимости когда - либо ? Часто основные версии являются маркетинговым, а не техническим решением; Абсурд Java происходит из-за того, что оба лагеря ведут его одновременно, почти комично.

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

- РЕДАКТИРОВАТЬ -
Я забыл упомянуть об этом, но Калеб хорошо указал на это: не используйте номера версий для обозначения чего-либо важного (например, стабильного / нестабильного), не делая это в других местах явным образом. Да, вы знаете, что нечетный младший номер версии указывает на развитие, но это делает один из нас. «Нестабильный» выпуск Debian - хороший пример; или вы также можете использовать совершенно другое название продукта; «Frozbot 1.2» для названия вашего продукта и «Devbot 1.3» для вашей версии разработки.

Когда нестабильная ветка считается стабильной, скажем, в 1.5.3, мы выпустим ее как 1.4.0.

Нет нет. Для нестабильной версии 1.5.3 стабильная должна начинаться с 1.6.0 (а 1.4.x просто пропустить, если вы хотите использовать семантическое управление версиями)

Вы пытаетесь использовать одно значение, чтобы указать две разные вещи.

Во-первых, у вас есть «версия», которая обычно служит для идентификации различных выпусков и указания порядка, в котором были выпущены выпуски. Как сказал Тайлерл, версия должна всегда увеличиваться - это не будет иметь никакого смысла для пользователей (и это также может вызвать большую внутреннюю путаницу), если вы измените версию с 1.5.3 на 1.4.0.

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

Это можно указать и то и другое с одним «номером версии,» так же , как некоторые магазины будут использовать некоторые схемы ценообразования , чтобы указать , является ли элемент в продаже. Например, цены, которые заканчиваются на «3» в магазине рядом со мной, являются окончательными ценами продажи. Это хорошо работает для сотрудников, которые быстро учатся определять цену продажи, но это не лучший способ рассказать своим клиентам о продаже. По этой причине они также ставят знаки возле предметов продажи. Вы можете сделать что-то подобное, например, сделать менее значимую цифру для стабильных выпусков и сделать ее странной для экспериментальных выпусков. Я думаю, однако, что если вы собираетесь выпустить что-то экспериментальное, вы должны четко пометить это так. Вы можете добавить 'X' в начале или конце строки версии, например:X.1.5.31.5.3.X, После этого вы можете даже указать номер экспериментальной версии, чтобы выпустить несколько экспериментальных версий, основанных на одной базовой версии: 1.5.3.X1, 1.5.3.X2.

Следует также учитывать , что существует давняя традиция использования «альфа» и «бета» версия номера для указания версии , которые не могут быть стабильными или полным: 1.5.3a54. Убедитесь, что у вас есть веская причина для отказа от этой схемы, если вы решите сделать что-то еще, потому что вам, вероятно, придется объяснить что-то еще вашему сообществу разработчиков.

Я бы предложил использовать формат major.minor.patch, используя расширение «tag» для стабильных / нестабильных версий и определенное значение старших и младших чисел:

major.minor.patch-stable|unstable

где

major  only changes if there are incompatible changes in the API
minor  changes if there are changes in the API but backward compatibility is given
patch  any other changes, could be the build number or any other increasing number
-stable indicates the stable version
-unstable indicates the unstable version

Таким образом, легко управлять зависимостями, и каждый клиент / пользователь будет сообщать, когда им следует уделять больше внимания новым версиям. Например, если компонент A (1.1.0-стабильный) зависит от B (5.4.534-стабильный) и должна появиться новая версия B (6.1.0-нестабильный), сразу же понимают, что A придется изменить, возможно, существенно ,

Мне очень нравится, как Hibernating Rhinos создавал RavenDb по сравнению с версиями - у них просто растет число сборок. Когда они получают стабильный, он становится стабильным. Но все это релиз-кандидат.