Было у меня две железки, изготовленных в соседней организации. Одна чуть более старая, другая чуть более новая.
Старая находилась внутри установки и работала неправильно. У меня было джва варианта:
1. Перепрошить старую железку новой прошивкой, надеясь, что там баг исправлен.
2. Заменить старую железку новой железкой, где прошивка уже новая.
Я решил пойти по второму пути, но старую всё равно пришлось бы прошивать, поэтому я связался с разработчиком и попросил последнюю версию прошивки. Когда-то, несколько месяцев назад, мы отлаживали эту железку, и разработчик присылал мне этих прошивок очень много. Но какая же из них была правильная? Последняя по дате-времени? Не факт! Лучше пусть сам мне пришлёт то, что надо.
Разработчик предложил мне своеобразное решение. Прошивка в данном устройстве не шифруется и не заблокирована от считывания. Можно скачать прошивку с новой железки и прошить в старую.
Тем не менее, я настоял на свежей сборке.
Сначала это показалось мне капризом. Типа, борьба за перфекционизм. Или желание перевесить часть работы на другого.
Но потом я обнаружил целых две причины, почему прошивать заведомо известные версии прошивок -- это правильно.
Первая причина: оказалось, что баг присутствует в новой железке тоже. Это означало одно из двух: либо прошивка новой железки всё же недостаточно новая, либо баг сохранился в новой прошивке. И при том, и при другом случае копирование прошивки из одной железки в другую не улучшило бы ситуацию. Поэтому лучше сразу заливать заведомо известную новую версию. Это исключит вероятность проявления тех багов, которые уже были исправлены ранее.
Вторая причина: если баг сохраняется даже в последней версии прошивки, тогда мы будем знать, что именно эта версия прошивки содержит баг. И, та-дам! У нас есть исходный текст, из которого мы только что прошивку собрали. С этим можно работать.
Частично такие проблемы можно (и нужно!) решать административным способом: а именно, каждая "стабильная" версия прошивки должна внутри себя содержать свой идентификатор, а разработчик должен иметь возможность вернуться к любой из выпущенных версий. Но мы живём не в сказке, а в реальности. И, увы, в реальности разработчики могут следить за коммитами, но могут не следить за их нумерацией в тексте прошивки. Эта ситуация усугубляется, если разработчик находится в отладочном угаре. В таких случаях я и сам номер версии не ставлю. Не до того.
Ещё немного про версии прошивок: diary.ru/~zHz00/p214802379_o-versionnosti.htm
Старая находилась внутри установки и работала неправильно. У меня было джва варианта:
1. Перепрошить старую железку новой прошивкой, надеясь, что там баг исправлен.
2. Заменить старую железку новой железкой, где прошивка уже новая.
Я решил пойти по второму пути, но старую всё равно пришлось бы прошивать, поэтому я связался с разработчиком и попросил последнюю версию прошивки. Когда-то, несколько месяцев назад, мы отлаживали эту железку, и разработчик присылал мне этих прошивок очень много. Но какая же из них была правильная? Последняя по дате-времени? Не факт! Лучше пусть сам мне пришлёт то, что надо.
Разработчик предложил мне своеобразное решение. Прошивка в данном устройстве не шифруется и не заблокирована от считывания. Можно скачать прошивку с новой железки и прошить в старую.
Тем не менее, я настоял на свежей сборке.
Сначала это показалось мне капризом. Типа, борьба за перфекционизм. Или желание перевесить часть работы на другого.
Но потом я обнаружил целых две причины, почему прошивать заведомо известные версии прошивок -- это правильно.
Первая причина: оказалось, что баг присутствует в новой железке тоже. Это означало одно из двух: либо прошивка новой железки всё же недостаточно новая, либо баг сохранился в новой прошивке. И при том, и при другом случае копирование прошивки из одной железки в другую не улучшило бы ситуацию. Поэтому лучше сразу заливать заведомо известную новую версию. Это исключит вероятность проявления тех багов, которые уже были исправлены ранее.
Вторая причина: если баг сохраняется даже в последней версии прошивки, тогда мы будем знать, что именно эта версия прошивки содержит баг. И, та-дам! У нас есть исходный текст, из которого мы только что прошивку собрали. С этим можно работать.
Частично такие проблемы можно (и нужно!) решать административным способом: а именно, каждая "стабильная" версия прошивки должна внутри себя содержать свой идентификатор, а разработчик должен иметь возможность вернуться к любой из выпущенных версий. Но мы живём не в сказке, а в реальности. И, увы, в реальности разработчики могут следить за коммитами, но могут не следить за их нумерацией в тексте прошивки. Эта ситуация усугубляется, если разработчик находится в отладочном угаре. В таких случаях я и сам номер версии не ставлю. Не до того.
Ещё немного про версии прошивок: diary.ru/~zHz00/p214802379_o-versionnosti.htm
03.05.2023 в 11:09
а вот об этом личном опыте поподробнее пжлст
06.05.2023 в 23:35
Обычно это решают добавлением дефайна, значение которого берётся из гита:
И потом выводить эту версию в --help; микроконтроллер, наверное, будет писать её в какой-то регистр или отдавать в ответ на какой-то запрос. Это пример для GCC/Clang и Make, но я думаю, что смысл понятен.
-- Minoru
07.05.2023 в 18:10
а что должно получиться?
я попробовал на репе без тегов, он просто вернул первые 5 цифр HEAD-коммита
более информативным было бы писать дату этого коммита, а не SHA-значение
07.05.2023 в 20:22
CD_Eater, а если в день было несколько коммитов?)
Вообще, у меня "ручной" номер версии как раз состоит из даты. Если (редко) получается больше одного "релиза" в день, то я помечаю завтрашним числом.