[Arlleex 328]

Какую стратегию вы используете?

Казалось бы, простой вопрос, но в реальности не совсем простой.

У меня любой девайс имеет зашитую HW-версию и FW-версию в виде MAJOR.MINOR.PATCH. Например, 1.0.0.

С FW обычно все просто: мажорная версия отражает глобальные изменения прошивки - т.е. функциональное наполнение проекта в целом. Например, прошивка версии 1.x.y не задействовала обмены по какой-то линии связи. В версии 2.x.y она задействуется, и по ней осуществляется обмен с какими-то внешними девайсами. Минорная циферка показывает номер стабильной версии ПО, т.е. она чуть детализирует мажорную цифру. Циферка патча наращивается при любом изменении текущего образа ПО, например, в процессе отлова багов - глобальный функционал не меняется, но для различения версий как раз служит патч-цифра.

То же самое с HW.

И вот тут появляется проблема. Например, разводится плата на другом МК. Версия HW меняется, но версия функционала ПО может не меняться: "извне" для разработчика функционал остается прежним. Т.е. циферки версии FW не должны меняться. Например, такое бывает, когда плата с одной и той же электрической схемой разводится по-разному конструктивно (поэтому версия HW меняется, чтобы удаленно можно было мониторить, что это за девайс). Но бывает и так, что плата меняется незначительно, но требует программных изменений (дергать лишнюю ножку, например). При этом фукцнионал девайса для стороннего наблюдателя не изменяется никак. В общем случае, рано или поздно, появляется зоопарк прошивок, на которых, вроде, и пишется версия ПО, но из них не понятно, с кем и чем она совместима🙂

А еще все сильно усугубляется различной применимостью одних и тех же девайсов: например, какая-нибудь CAN-клавиатура может отличаться только измененным битрейтом и набором рабочих CAN-ID. Т.е. появляется некое техлицо/исполнение.

Может, есть весьма строгий и проверенный временем метод контроля и присвоения версий?

P.S. Мда. Стоило ведь отправить пост, как через пять минут поисков наткнулся на замечательный сайт: https://semver.org/. 100% попадание.

[amaora 36]

Не версионирую, метаинформация ПО только CRC32, дата сборки и короткое название ревизии платы. Иногда могут быть теги или номера ревизии из VCS.

Edited April 9, 2025 by amaora

[Arlleex 328]

1 час назад, amaora сказал:

Не версионирую, метаинформация ПО только CRC32, дата сборки и короткое название ревизии платы. Иногда могут быть теги или номера ревизии из VCS.

А позвольте узнать номенклатуру в год? У меня порядка десятка девайсов/год, и каждый развивается/применяется в разных проектах... Под каждый случай возможны кастомные версии прошивок - их зоопарк разных, с разными возможностями и т.д. Опять же - как идентифицируете девайсы? У меня централизованная сервисная поддержка - т.е. удаленно могу обновить по желанию заказчика, но при этом сначала должен знать, что конкретно у него на руках - т.е. какое железо и т.д.

[amaora 36]

36 minutes ago, Arlleex said:

А позвольте узнать номенклатуру в год?

Порты под новые платы делаю не часто 1-2 в год, всего их около ~10. Стараюсь сводить все к переназначению пинов и вкл/выкл периферийных блоков. Прошивка унифицированная, когда добавляю новые функции то они появляются у всех, если не завязаны на железо. Вместо зоопарка версий предпочитаю возможность конфигурирования во время работы. Для каждого варианта железа в проекте отдельный файл описания, в результате сборки получается ~10 вариантов прошивок. Многие параметры из файла описания платы можно изменить уже во время работы и сохранить конфигурацию во флеш, например диапазоны датчиков, параметры NTC резисторов. Устройства не сетевые, работа с ними возможна по интерфейсам UART, CAN, USB. Удалённо можно конфигурировать если пробросить UART например, но без физического доступа или видеосвязи не всегда имеет смысл. Обновление автоматическое не делал (технические сложности). Какое железо я могу однозначно понять, при условии что там уже моя прошивка. Не все платы моей разработки или заказчиков, есть сторонние которые можно купить на али, чем их прошивать определяется по таблице в документации.

Есть ещё GUI ПО для настроек и управления, которое условно может работать с разными версиями прошивки, но желательно иметь версии с одной ревизии. Протокол связи текстовый, терпимый ко многим изменениям и тоже без версионирования. Политика обновления - всегда берём новую версию прошивки для своего железа и новый GUI.

Это проект с открытым кодом, устройства я не произвожу, со всеми заказчиками работа строится по разному, от ТК РФ до собирают и пользуются как-то сами.

[Arlleex 328]

Понятно. Конфигурация девайсов у меня тоже может делаться отдельно: но это не функциональные, в основном, моменты: как раз какие-то константы, калибровочные значения и т.д. Но это другое... Без версионности сложно, ИМХО, поддерживать ЖЦ девайсов. Особенно когда девайсов тысяча, находятся они в разных местах, где-то платы с одним чипом (МК), где-то с другим. При удаленной прошивке приходится понимать, что за блок и чем его обновлять.

[quаrk 73]

6 часов назад, Arlleex сказал:

Какую стратегию вы используете?

Казалось бы, простой вопрос, но в реальности не совсем простой...

Может, есть весьма строгий и проверенный временем метод контроля и присвоения версий?

Для себя, этот вопрос решил давно и окончательно:

Версия продукта - это дата его выпуска, записанная в обратной последовательности, для удобства поиска и сортировки. Например, продукт выпущенный сегодня будет иметь, кроме своего названия (имени), номер версии: 2025.04.10.

Если вы настолько "плодовиты", что выпускаете по несколько версий одного и того же продукта в день, то добавляете к номеру версии еще текущее время. Например: 2025.04.10.01.32.15. При необходимости, точно таким же способом присваиваются серийные номера конкретным экземплярам изделий.

Все. Не надо придумывать ничего лишнего. Пользуюсь этой системой уже много-много лет и не знаю ни каких проблем.

Периодически, разные люди пытались навязать мне свою собственную систему версий. На что всегда был только один вопрос - кто будет эту систему поддерживать? Контролировать правильность ее применения, вести "реестр версий". Тратить на это свое время. И кто будет этому человеку платить за этот, по сути, бессмысленный труд? Обычно, на этом дискуссия заканчивалась сама собой...

[siargy 17]

12 hours ago, Arlleex said:

У меня любой девайс имеет зашитую HW-версию и FW-версию

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

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

[Arlleex 328]

5 часов назад, quаrk сказал:

Для себя, этот вопрос решил давно и окончательно:

Версия продукта - это дата его выпуска, записанная в обратной последовательности, для удобства поиска и сортировки. Например, продукт выпущенный сегодня будет иметь, кроме своего названия (имени), номер версии: 2025.04.10.

Если вы настолько "плодовиты", что выпускаете по несколько версий одного и того же продукта в день, то добавляете к номеру версии еще текущее время. Например: 2025.04.10.01.32.15. При необходимости, точно таким же способом присваиваются серийные номера конкретным экземплярам изделий.

Все. Не надо придумывать ничего лишнего. Пользуюсь этой системой уже много-много лет и не знаю ни каких проблем.

Периодически, разные люди пытались навязать мне свою собственную систему версий. На что всегда был только один вопрос - кто будет эту систему поддерживать? Контролировать правильность ее применения, вести "реестр версий". Тратить на это свое время. И кто будет этому человеку платить за этот, по сути, бессмысленный труд? Обычно, на этом дискуссия заканчивалась сама собой...

На больших номенклатурах/линейках девайсов это не работает. Никакая дата вообще не нужна, ИМХО, ибо это ни о чем не говорящие цифры. Только наращивание соответствующей части версии. Это проще воспринимать, как минимум.

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

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

Да даже собирая на одном тулзе, бывает, не нужно изменять номер версии (более того, даже CRC образа должна будет сойтись с предыдущей), чтобы не было геммора и лишних вопросов. При различных сертификациях полезно: могут попросить показать процесс сборки ПО из исходников, а после сборки смотрят заявленные атрибуты образа как на компе, так и через сервис-утилиты девайса. Время/дата сразу отметается.

[adnega 15]

Пользуюсь системой MAJOR[8].MINOR[8].BUILD[16] (в скобках число бит для хранения числа).

MAJOR - должен быть один на все варианты исполнения.

MINOR - это взаимозаменяемые, но функционально очень разные исполнения.

BUILD - возрастающий счетчик (обычно один на все возможные исполнения).

На одном и том же железе можно сделать разные функциональные исполнения - у них будет разный MINOR. Причем, MINOR=0 - для обозначения загрузчиков.

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

Но для всех прошивок с одинаковым MAJOR можно без проблем жонглировать функционалом с различными MINOR путем замены прошивки.

Например:

v2.0.3 - загрузчик версии 3

v2.1.37 - тестовая сборка для проверки аппаратной части.

v2.2.37 - контроллер "регулятор давления"

v2.3.39 - контроллер "регулятор давления (спаренный)"

v2.4.20 - контроллер "подогреватель"

и т.д.

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

Например, 

v1.x.x - регуляторы первой версии, v2.x.x - регуляторы на новом МК;

v1.x.x - автоинформатор макет, v2.x.x - автоинформатор GPS, v3.x.x - автоинформатор LTE и т.д.

[quаrk 73]

43 минуты назад, Arlleex сказал:

На больших номенклатурах/линейках девайсов это не работает...

Как раз, на больших объемах номенклатуры и номерных серийных изделиях - это работает лучше всего. Не знаю, как у Вас, у меня все архивы организованы в хронологическом порядке. Версия ПО сразу дает точную дату его генерации, а серийный номер - точную дату выпуска данного конкретного экземпляра изделия. Сразу идёте в архив по указанным датам и имеете полную информацию и по данной версии ПО, и по данному конкретному экземпляру изделия. Просто, дешево и сердито. И ни какая система контроля версий не нужна. От слова "совсем".

P.S. Время от времени, ко мне обращаются заказчики с просьбой найти утерянную ими информацию по изделию, которое иногда было изготовлено лет 10-15 назад. Еще не было случая, чтобы все, что нужно, не нашлось в течение пары минут...

P.P.S. Собственно, дело, конечно, Ваше - иметь или не иметь.
Геморрой, в данном случае. В виде системы контроля версий. 

Edited April 10, 2025 by quаrk

[Arlleex 328]

42 минуты назад, quаrk сказал:

И ни какая система контроля версий не нужна. От слова "совсем".

На этом можете не продолжать дальше свои рассуждения.

[quаrk 73]

2 минуты назад, Arlleex сказал:

На этом можете не продолжать дальше свои рассуждения.

ОК.

Вы свой выбор сделали....

[mantech 131]

14 часов назад, Arlleex сказал:

У меня любой девайс имеет зашитую HW-версию и FW-версию в виде MAJOR.MINOR.PATCH. Например, 1.0.0.

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

1 час назад, adnega сказал:

v2.0.3 - загрузчик версии 3

v2.1.37 - тестовая сборка для проверки аппаратной части.

v2.2.37 - контроллер "регулятор давления"

v2.3.39 - контроллер "регулятор давления (спаренный)"

v2.4.20 - контроллер "подогреватель"

Т.е. вы сами для себя все зашифровали, вопрос - зачем?)))

Замена прошивки определяется аппаратной частью, т.е. если контроллер на чипе IMX, то на него однозначно не пойдет прошивка от аллвиннера и пр...

[quаrk 73]

2 часа назад, siargy сказал:

... ну и дату производства неплохо бы зашить.

Именно её и стоит зашить. В виде версии ПО и/или серийного номера изделия (в правильном написании). А все остальное - лишнее...

[jcxz 356]

56 минут назад, mantech сказал:

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

Адептов создания номера версии по дате прошу ответить - как решить следующие вопросы:

1. Версии: "08.01.25" и "18.08.24" - как узнать сколько версий прошло между ними? Насколько стара одна относительно другой?
2. Как определить - каков характер важности модификаций в прошивке: "чуть-чуть поправили" или "всё переделали"?
3. Если прошивка выпускается на сторону с обязательством "отладочная, предназначена только для ограниченного списка девайсов; никому постороннему в руки не давать!" (например - для опытной эксплуатации где-то, где шить будут посторонние человеки) - как опознать такую по версии из её даты? А вы там заложили нечто отладочное, что никак нельзя выпускать в массы...  
4. В случае классической системы, есть например текущая релизная версия: v01.05.00 (релизность её определяется тем фактом, что последняя группа цифр == 00); решено сделать серьёзную переделку в ПО устройства, которая требует много времени. По ходу переделки выпускаются бета-версии для отладки на объекте заказчика = v02.xx.xx, но до релиза ещё далеко. И тут - в официальном релизе v01.05.00 вылез серьёзный баг, который нужно срочно поправить, не дожидаясь нового релиза v2.xx.00. Что делать??? Как не запутаться потом в случае с версиями по дате? В классической системе просто делаем быструю правку/заплату на v1.05.00, выпускаем v1.05.01 и отправляем заказчику. По номерам версий видим, что хоть v1.05.01 более нова по дате выпуска, но более стара по функционалу, чем линейка v2.xx.xx. Также по номеру v01.05.01 сразу видим - что это временная, заплатная версия, которую потом нужно обновить до релизной. Что делать в случае версий по дате???

 

Версии "по дате" - бред. Крайне неудобно. Никогда так не делали и не делаем. Так как в реальной практике с ними будет куча гемора.

Насчёт чтобы "не забыть когда создавали": Никто же не мешает кроме номера версии держать в прошивке и дату/время её компиляции? Я именно так и делаю: кроме номера версии, в бинарнике прошивке имеется текстовая сигнатура. Которая содержит и дату время/компиляции; и версию; и аппаратные особенности исполнения для которых компилили; можно даже идентификатор ПК на котором компилили; ...etc. И CRC32 в прошивке тоже имеется. А в некоторых проектах - и SHA256 имеется.

 

PS: Насчёт правил версификации: Тут надо самому ТС определяться. Вряд-ли кто-то посоветует что-то подходящее. Так как условия работы у всех разные. Под них и нужно строить систему версионирования.

32 минуты назад, quаrk сказал:

Именно её и стоит зашить. В виде версии ПО и/или серийного номера изделия (в правильном написании). А все остальное - лишнее...

Бред.

8 часов назад, quаrk сказал:

кто будет эту систему поддерживать? Контролировать правильность ее применения, вести "реестр версий". Тратить на это свое время.

Странно как-то: даты в архиве прошивок вы почему-то можете хранить (и тратить на них своё время), а номера версий - не можете. Отчего так?