Мы пытаемся выбрать хороший способ нумерации версий для программных компонентов, которые зависят друг от друга.
Давайте будем более конкретными:
Программный компонент 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.6.0 (а 1.4.x просто пропустить, если вы хотите использовать семантическое управление версиями)
источник
Вы пытаетесь использовать одно значение, чтобы указать две разные вещи.
Во-первых, у вас есть «версия», которая обычно служит для идентификации различных выпусков и указания порядка, в котором были выпущены выпуски. Как сказал Тайлерл, версия должна всегда увеличиваться - это не будет иметь никакого смысла для пользователей (и это также может вызвать большую внутреннюю путаницу), если вы измените версию с 1.5.3 на 1.4.0.
Во-вторых, вы пытаетесь указать, является ли данная версия стабильной или нет.
Это можно указать и то и другое с одним «номером версии,» так же , как некоторые магазины будут использовать некоторые схемы ценообразования , чтобы указать , является ли элемент в продаже. Например, цены, которые заканчиваются на «3» в магазине рядом со мной, являются окончательными ценами продажи. Это хорошо работает для сотрудников, которые быстро учатся определять цену продажи, но это не лучший способ рассказать своим клиентам о продаже. По этой причине они также ставят знаки возле предметов продажи. Вы можете сделать что-то подобное, например, сделать менее значимую цифру для стабильных выпусков и сделать ее странной для экспериментальных выпусков. Я думаю, однако, что если вы собираетесь выпустить что-то экспериментальное, вы должны четко пометить это так. Вы можете добавить 'X' в начале или конце строки версии, например:
X.1.5.3
1.5.3.X
, После этого вы можете даже указать номер экспериментальной версии, чтобы выпустить несколько экспериментальных версий, основанных на одной базовой версии:1.5.3.X1
,1.5.3.X2
.Следует также учитывать , что существует давняя традиция использования «альфа» и «бета» версия номера для указания версии , которые не могут быть стабильными или полным:
1.5.3a54
. Убедитесь, что у вас есть веская причина для отказа от этой схемы, если вы решите сделать что-то еще, потому что вам, вероятно, придется объяснить что-то еще вашему сообществу разработчиков.источник
Я бы предложил использовать формат major.minor.patch, используя расширение «tag» для стабильных / нестабильных версий и определенное значение старших и младших чисел:
где
Таким образом, легко управлять зависимостями, и каждый клиент / пользователь будет сообщать, когда им следует уделять больше внимания новым версиям. Например, если компонент A (1.1.0-стабильный) зависит от B (5.4.534-стабильный) и должна появиться новая версия B (6.1.0-нестабильный), сразу же понимают, что A придется изменить, возможно, существенно ,
источник
Мне очень нравится, как Hibernating Rhinos создавал RavenDb по сравнению с версиями - у них просто растет число сборок. Когда они получают стабильный, он становится стабильным. Но все это релиз-кандидат.
источник