Версионирование в embedded

@DOOMSDOY · Регистрация: 13.07.2012

Author24 — интернет-сервис помощи студентам

Друзья и коллеги, здравствуйте!
Назрел у меня в очередной раз вопрос, который я вот уже пол-года не могу для себя решить с помощью гугления, и вот решил, что может вы что-то имеете за это сказать.
А вопрос, который хочется обсудить, о присвоении версий программным проектам при разработке ПО для встраиваемых систем. Для меня этот вопрос стоит в контексте использования VCS (системы контроля версий) mercurial, хотя вариант перехода на git тоже не отметаем, если в этом будет какой профит.
Давайте обсудим кто и как нумерует версии прошивок, интересует структура, которую вы используете (например, классические Major.Minor.Patch, или нечто иное), принцип инкремента каждой составляющей и механизмы реализации этого.
А основной интерес вызывает то, какими способами этот процесс хоть частично автоматизировать? Например менять самый младший номер при сохранении коммита или как-то ещё?

Вручную плохо получается, приходится кроме разработки поддерживать сразу несколько проектов, даже по несколько программных модулей (3 и больше) для одного устройства, иногда забываю вовремя присвоить версию и начинаю сам в этом путаться. Хочется какой-то определённости и простоты. Например, вручную менять Major, когда теряется обратная совместимость, Minor, когда добавлен новый функционал, а самую младшую часть чтобы инкрементировал некий скрипт или нечто похожее. Тогда, разделив разработку каждой из Major-версий в отдельную ветку СКВ уже становится проще ориентироваться в дереве проекта и быстро находить любую версию просто по номеру. Ещё добавить учёт версии железа для которого создана эта ветка и будет, как мне кажется, идеально.

Надеюсь, получилось не слишком сумбурно изложить суть вопроса.
Кто и как решает эти вопросы для себя, есть ли вообще способы это сделать применительно к нашим реалиям? Есть ли удобные инструменты, о которых я просто не знаю, или надо скриптами это как-нибудь разруливать?
Нужны любые мысли и идеи по этому поводу. Да и просто статистика. Прошу высказаться.

@Iddy_Im · 17.11.2016, 15:18

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

Код

// version.h
const char* version = "01.01.999";

и кусок скрипта:

Код

V=$(grep version version.h| sed s/.*"\([^.]*\).\([^.]*\).\([^.]*\).".*/M=\1;m=\2;r=\3/)
eval $V
r=$((r+1))
echo "const char* version = \"$M.$m.$r\";" > version.h

@div · 17.11.2016, 15:25

Major/Minor/HW - вручную. К ним добавляется автоматом (Makefile) номер ревизии из VCS. Опционально, + имя ветки - зависит от VCS. Номер ревизии не обязан быть монотонно возрастающим, это просто текстовый идентификатор.

Embeddid тут ничем не отличается от прочих.

@itysiy · 17.11.2016, 16:58

Сообщение от DOOMSDOY

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

У меня чуть по-другому. Часто Major.Minor.Patch. Патч инкрементирую не с каждым коммитом, а только тогда, когда прошивка ушла в работу (девайс с этой прошивкой был где-то установлен, продан, покинул мой стол). Если при изменении теряется совместимость, либо происходят значительные изменения - инкрементируется минор. Мажор инкрементирую очень редко. Как правило он означает очень значительное обновление девайса. Для простых проектов чаще я не использую мажор, поэтому у меня версии двухциферные.
Такую версионность делаю и для ПО и для железа. Одно время пытался кодировать совместимость железа и ПО в версиях: если минор одинаков - значит железо и ПО совместимы. Было вроде как удобно, было легко объяснять сервисникам принцип. Но из-за этого версии скакали вперед, были проблемы, когда вроде для ПО нужно увеличить Минор, но оно все же совместимо с предыдущей версией железа. Уже не помню как решал эти вопросы.
Сейчас пока для себя решил, что так как печатные платы обновляются не так просто как софт, то имеет смысл сделать для него одноциферную версионность. И в документации хранить таблицу совместимости разных версий ПО к разным ревизиям железа.
Еще сложнее когда проект раздваивается и растраивается. Тут уже, как мне кажется нужно максимально стараться делить ПО на библиотеки, выносить общий скелет отдельно со своим версированием, и делать раздельные проекты, использующий основной скелет как библиотеку. Так же в документации хранить совместимость версий проекта с версией основного скелета.

@dikor · 17.11.2016, 18:19

Тут ещё нужно как-то учитывать версию (ревизию) железа. У меня железо меняется тоже часто, и не всегда прошивка сама может определить конфигурацию.

@omooro · 17.11.2016, 18:22

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

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

@pitrpts · 18.11.2016, 11:54

При архивировании предпочитаю добавлять к номеру проекта дату и время
в некоторых программах по просьбам трудящихся Галку поставили

https://www.cyberforum.ru/savedimages/2016/11/18/gmnddfptbdkevxvuucy4la.jpg

@DOOMSDOY 0 / 0 / 0 Регистрация: 13.07.2012 Сообщений: 566
		1
	Версионирование в embedded 17.11.2016, 14:41. Показов 5440. Ответов 6 Метки нет (Все метки) Друзья и коллеги, здравствуйте! Назрел у меня в очередной раз вопрос, который я вот уже пол-года не могу для себя решить с помощью гугления, и вот решил, что может вы что-то имеете за это сказать. А вопрос, который хочется обсудить, о присвоении версий программным проектам при разработке ПО для встраиваемых систем. Для меня этот вопрос стоит в контексте использования VCS (системы контроля версий) mercurial, хотя вариант перехода на git тоже не отметаем, если в этом будет какой профит. Давайте обсудим кто и как нумерует версии прошивок, интересует структура, которую вы используете (например, классические Major.Minor.Patch, или нечто иное), принцип инкремента каждой составляющей и механизмы реализации этого. А основной интерес вызывает то, какими способами этот процесс хоть частично автоматизировать? Например менять самый младший номер при сохранении коммита или как-то ещё? Вручную плохо получается, приходится кроме разработки поддерживать сразу несколько проектов, даже по несколько программных модулей (3 и больше) для одного устройства, иногда забываю вовремя присвоить версию и начинаю сам в этом путаться. Хочется какой-то определённости и простоты. Например, вручную менять Major, когда теряется обратная совместимость, Minor, когда добавлен новый функционал, а самую младшую часть чтобы инкрементировал некий скрипт или нечто похожее. Тогда, разделив разработку каждой из Major-версий в отдельную ветку СКВ уже становится проще ориентироваться в дереве проекта и быстро находить любую версию просто по номеру. Ещё добавить учёт версии железа для которого создана эта ветка и будет, как мне кажется, идеально. Надеюсь, получилось не слишком сумбурно изложить суть вопроса. Кто и как решает эти вопросы для себя, есть ли вообще способы это сделать применительно к нашим реалиям? Есть ли удобные инструменты, о которых я просто не знаю, или надо скриптами это как-нибудь разруливать? Нужны любые мысли и идеи по этому поводу. Да и просто статистика. Прошу высказаться. 0

@Iddy_Im 0 / 0 / 0 Регистрация: 21.11.2012 Сообщений: 1,400
	17.11.2016, 15:18	2
	Предлагаю не вручную коммиты делать, а баш-скриптик накатать, который будет инкрементировать номер релиза (уж мажорную и минорные версии таки лучше вручную изменять), а потом коммитить и пушить. Версию можно хранить в отдельном подключаемом файле, а ее адрес зафиксировать в линкере. Тогда и внутри прошивки будет возможность номер версии посмотреть. Вроде того: Код // version.h const char* version = "01.01.999"; и кусок скрипта: Код V=$(grep version version.h\| sed s/."\([^.]\).\([^.]\).\([^.]\)."./M=\1;m=\2;r=\3/) eval $V r=$((r+1)) echo "const char version = \"$M.$m.$r\";" > version.h 0

@div 0 / 0 / 0 Регистрация: 26.01.2009 Сообщений: 3
	17.11.2016, 15:25	3
	Major/Minor/HW - вручную. К ним добавляется автоматом (Makefile) номер ревизии из VCS. Опционально, + имя ветки - зависит от VCS. Номер ревизии не обязан быть монотонно возрастающим, это просто текстовый идентификатор. Embeddid тут ничем не отличается от прочих. 0

@itysiy 1 / 1 / 0 Регистрация: 18.01.2012 Сообщений: 1,418
	17.11.2016, 16:58	4
	Сообщение от DOOMSDOY Например, вручную менять Major, когда теряется обратная совместимость, Minor, когда добавлен новый функционал, а самую младшую часть чтобы инкрементировал некий скрипт или нечто похожее. У меня чуть по-другому. Часто Major.Minor.Patch. Патч инкрементирую не с каждым коммитом, а только тогда, когда прошивка ушла в работу (девайс с этой прошивкой был где-то установлен, продан, покинул мой стол). Если при изменении теряется совместимость, либо происходят значительные изменения - инкрементируется минор. Мажор инкрементирую очень редко. Как правило он означает очень значительное обновление девайса. Для простых проектов чаще я не использую мажор, поэтому у меня версии двухциферные. Такую версионность делаю и для ПО и для железа. Одно время пытался кодировать совместимость железа и ПО в версиях: если минор одинаков - значит железо и ПО совместимы. Было вроде как удобно, было легко объяснять сервисникам принцип. Но из-за этого версии скакали вперед, были проблемы, когда вроде для ПО нужно увеличить Минор, но оно все же совместимо с предыдущей версией железа. Уже не помню как решал эти вопросы. Сейчас пока для себя решил, что так как печатные платы обновляются не так просто как софт, то имеет смысл сделать для него одноциферную версионность. И в документации хранить таблицу совместимости разных версий ПО к разным ревизиям железа. Еще сложнее когда проект раздваивается и растраивается. Тут уже, как мне кажется нужно максимально стараться делить ПО на библиотеки, выносить общий скелет отдельно со своим версированием, и делать раздельные проекты, использующий основной скелет как библиотеку. Так же в документации хранить совместимость версий проекта с версией основного скелета. 0

@dikor 0 / 0 / 0 Регистрация: 07.03.2010 Сообщений: 918
	17.11.2016, 18:19	5
	Тут ещё нужно как-то учитывать версию (ревизию) железа. У меня железо меняется тоже часто, и не всегда прошивка сама может определить конфигурацию. 0

@omooro 0 / 0 / 0 Регистрация: 11.06.2010 Сообщений: 351
	17.11.2016, 18:22	6
	Тоже думал над таким вопросом. Не стал усложнять, вручную задаю название версии, да именно название, а не просто номер. Вбиваю туда номер ревизии VCS и какой нибудь суффикс. Эта версия нужна для того, чтобы понять из каких исходников собран код, какие у нее особенности. Дальше задаю название ревизии платы для которой предназначен прошив, тоже вручную, разных версий пока не держу, старые не поддерживаю, когда будет надо сделаю отдельные ветки в VCS для начала, если их станет много то будет выбор HAL при компиляции. И еще номер версии блока конфигурации который записывается во флеш. Этот номер проверяется автоматически при чтении из флеш, если прошив перестал понимать старые данные то используется дефолт. Каждый раз когда я несовместимо меняю состав сохраняемых параметров увеличиваю этот номер на единицу. Для протоколов возможно будет так же отдельное версионирование, пока протоколов нет. Пока считаю, что автоматическая генерация версии исходя из даты и ревизии VCS не нужна. Не хочется, чтобы каждый раз ворочался какой-то скрипт и каждый раз пересобирался лишний модуль. Релизы надо готовить в ручную. 0

@pitrpts 0 / 0 / 0 Регистрация: 30.04.2015 Сообщений: 721
	18.11.2016, 11:54	7
	При архивировании предпочитаю добавлять к номеру проекта дату и время в некоторых программах по просьбам трудящихся Галку поставили https://www.cyberforum.ru/savedimages/2016/11/18/gmnddfptbdkevxvuucy4la.jpg 0