[dxp 33]

У меня из git обычно забирается такой командной, которая выполняется автоматом перед компиляцией:

git log --pretty=format:"(%ad %h)" --abbrev-commit --date=short -1

результат потом попадает в h-файл. Получается в итоге:

#define GITHASH "(2017-02-03 db74878)"

в итоге и дату видно и не нужен длинючий hash. По дате можно определить "новизну" билда, а по hash найти конкретный коммит

+1. И совсем дело в командной или не командной разработке. Всё автоматизировано. Кроме того, если версия отдаётся в продакшн, то её (я про git) желательно пометить меткой, в этом случае можно использовать имя метки, которое можно сделать максимально осмысленным.

[juvf 10]

спор о том, что лучше PAL или SECAM. Правостороннее движение или левостороннее. На вкус и цвет товарищей нет.

 

ps

#define GITHASH "(2017-02-03 db74878)"

ну вот мне не понятно что было раньше... например 2017-02-03 или 2017-03-02? И во вторых.... как по db74878 найти в гите 734713bc047d87bf7eac9674765ae793478c50d3?

в 3-их: у пользователя (или у наладчика на флешке) есть две сборки "(2017-02-03 db74878)" и "(2017-02-03 df56a87)" - какая свежея?

 

я пробовал прикрутить контроль версий.... не вкатило.... не понравилось. Системы контроля версий (СКВ) вообще может не быть, а автобилд нужен... да и с автобилдом тоже всё автоматизировано. ведётся журнал ревизий, по номеру билда и дате сборки можно быстро найти нужную ревизию (если есть СКВ).

В документации точно так же ведется список фич и пофиксенных багов по билдам и информативность такая же

+1

[johnshadow 1]

ps ну вот мне не понятно что было раньше... например 2017-02-03 или 2017-03-02?

А как вы в оффлайне определяете такое написание? Например на сроке годности продуктов?

в readme проекта можно указать формат интерпретации даты yyyy-dd-mm или yyyy-mm-dd - для новых

участников проекта. Там же можно указать и стили оформления кода и т.п.

И во вторых.... как по db74878 найти в гите 734713bc047d87bf7eac9674765ae793478c50d3?

Уверяю вас - это возможно. Вы же не думаете, что короткий hash создатели git придумали just for fun?

И еще момент - "db74878" это первые символы полного hash.

в 3-их: у пользователя (или у наладчика на флешке) есть две сборки "(2017-02-03 db74878)" и "(2017-02-03 df56a87)" - какая свежея?

я пробовал прикрутить контроль версий.... не вкатило.... не понравилось.

Два варианта:

1) выводить в переменную и время. для избегания разночтений - в UTC.

2) в логе git посмотреть полную дату-время коммитов.

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

 

[juvf 10]

А как вы в оффлайне определяете такое написание? Например на сроке годности продуктов?

Ни как. На продуктах пишут 07.02.2017, другого написания не встречал. 2017.07.02 - такое написание не определяется.

 

2) в логе git посмотреть полную дату-время коммитов.

в каком логе? ещё раз... вводная.... наладчик/пользователь поехал на обновление ПО в устройстве. на флешке две прошивки... какая свежея? Нету ни проетка, ни клиента гит, ни инета....

 

в readme проекта можно указать формат интерпретации даты

какое ридми? пользователь должен зайти в эбаут приложения и должен увидеть номер сборки и/или дату и время сборки, и/или номер версии. И должен понять, на сколько программа свежая.

 

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

вы так говорите, какбудь-то я вас убеждаю не использовать версирование сборок. Я предложил свой вариант. Они ни чем не хуже вашего. По мне, так он удобнее, чем брать его из СКВ. на вскидку.... откройте в хроме chrome://help/ - Версия 55.0.2883.87. Нету ни каких диких хэшей из гита, нет даты... Объясните гуглу, что они не правильно версию пишут, и скажите им Контроль версий, как и баэкапы можно не любить, но жизнь вынуждает их применять... рано или поздно.

По мойму в qip было Версия 2005 build 8095.... Firefox - 51.0.1, FreeCommander XE 2016 Build 715, в нотепад++ версия и время сборки.... во всех программах версия/сборка/время сборки.... привязки к номерам ревизий из СКВ не встречал.... хотя не значит что их нет, и не значит, что это плохой способ... просто мне удобней автобилдом контролировать номера релизов.

[johnshadow 1]

просто мне удобней автобилдом контролировать номера релизов.

Вы с этим проектом один работаете? Как без систем контроля версии выполняете модификацию кода?

Т.е. каким образом разделяете релизную копию и копию в которой сейчас вносите изменения?

Нету ни каких диких хэшей из гита, нет даты...

По поводу билдов. Зайдите в FireFox в about:buildconfig и обнаружите:

Built from https://hg.mozilla.org/releases/mozilla-beta/rev/d171c36d484800b1bb00db1612460a7120dd2fdf

Аналогично для Хрома в about:version:

Версия    0e9a9a6f3676ae439b78cd9b3f62b4193c3ac7d5-refs/branch-heads/2924@{#895}

Изменено 7 февраля, 2017 пользователем johnshadow

[juvf 10]

Как без систем контроля версии выполняете модификацию кода?

Т.е. каким образом разделяете релизную копию и копию в которой сейчас вносите изменения?

Давайте отделим мух от котлет. Я свой код контролирую либо с помощью svn, либо с помощью git (есть и cvs). Я использую систему контроля версий. Хотя не во всех проектах. если программа простая... её дольше в СКВ заносить, чем писать.

Что касается сборок.... не ревизий, а именно сборок. Есть задача - точно знать, какую версию использует пользователь и какую версию заливает. Для этого я во всех проектах применяю номер сбрки и/или время и дату сборки. номер сборки автоматически инкримитируется при компиляции. К СКВ номер сборки не привязан, как и СКВ к номеру сборки. Релизная копия отделена от проекта.... собирается релиз и выкладывается в общее хранилище, от куда релиз могут взять производство и служба сервиса. В хранилище лежат все релизные сборки... от 1 до 1234. Релизу задается имя name_1234.hex, 1234 - номер сборки. Там же в хранилище ведётся редми, с указанием изменений.

 

ps допустим пользователь обнаружил проблему.... говорит, что у него сборка 1201. Я вижу, что текущая 1234. Если проблема новая... то я буду эту проблему искать и устранять в 1234 и если найду, то выпущу 1235 и отправлю пользователю. Если проблема была.... то она решена гденить в 1220.... я просто отправлю ему 1234.

 

1)зачем по билду искать в репозитории релиз сборки 1201?

ну допустим вы захотите откатиться на 1201 и поискать там проблему и потом проверить есть ли она в 1234.... допустим.... но

2)вам чтоб откатится до билда 1201, от пользователя нужен хэш от гита? если он вам сообщит, что он пользуется хромом версии 55.0.2883.87, вы от него потребуете сообщить версию ad0be09aa3ca814168d079b52825f6f80e22f0e8-refs/branch-heads/2883@{#723}? Не думаю.... я думаю вы по 55.0.2883.87 сами найдете нужный релиз и нужный срез. тогда вопрос - зачем пихать в ПО этот жуткий хэш? Как говориться: в чем профит?

[johnshadow 1]

Как говориться: в чем профит?

Так ведь в распределенных СКВ нет возможности проводить сквозную нумерацию билдов\коммитов.

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

У меня свои номера билдов теперь, у вас свои. И как их дальше сравнивать?

На mercurial пытались прикрутить сквозную нумерацию, но по моему это отход от идеологии распределенных СКВ.

А так как есть дата коммита, то полный hash для однозначного определения конкретного коммита и не нужен.

 

 

[juvf 10]

У меня свои номера билдов теперь, у вас свои. И как их дальше сравнивать?

в ветках нет инкримента билдов. зачем в ветках билд? все сливается в основной ствол, тестится в основном стволе. потом, при сборке релиза из ствола происходит инкримент билда.

а в ветках не нужен билд. ветки - это для разрабов. Вообще разрабам, если они работают в скв, им не нужен билд. Они по логу комитов могут всё определить... и время сборки, и какие изменения были введены, и что в каих сырцах правлено. Билд нужен, чтобы можно было определить, какую версию использует пользователь, на сколько свежую.

 

ps да даже если и возникнет конфликт билда.... например 2 чела работают в стволе и оба собрали релиз. ну и что? во время комита будет конфликт с 1 строчкой.... #define BUILD 715 и #define BUILD 720.... при слиянии используй #define BUILD 720. Это не проблема.

 

pps только у руководителя проекта в IDE происходит вызов скрипта pre-build или post-build, который инкреметирует билд.... поэтому хоть 100 чел делают релиз.... только руководитель его автоматом проинкреметирует.

[johnshadow 1]

все сливается в основной ствол, тестится в основном стволе.

Вот где у нас идеологическая разница - у меня в master попадает только проверенный код, который прошел

тестирование в том числе и на группе реальных устройств у клиентов (которые согласились стать бета-тестерами). Таким образом в любой

момент из master всегда можно собрать "стабильный" релиз. И как у релизов, так и у бета-сборок

однотипный вывод версии - типа "XX.YY дата коммита и короткий hash". Где XX.YY это мажорные и минорные значения версии,

которые правятся руками (может быть и тэгом и git).

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

1) Релизная, вида: "XX.YY.buil_num"

2) Бета, вида: "commit_hash" или что-то подобное

Т.е. имеем две сущности (два вида), хотя фактически можно обойтись одной: только второй, так как первая не может быть универсальной,

ведь она поддерживается только в master ветке. Стоит ли плодить сущности без их необходимости?

 

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

[juvf 10]

ну не понимаю я зачем нужен хэш конечному юзеру... не понимаю. ))) Это какой-то оверинженеринг. И ни в одной проге я не видел хэшей в Эбаутах. даты сборок есть, билды есть, минор.мажор - есть, но хэшЫ!!! Открыл версию прошивки на смартфоне - %имя_тела%_20160630. Нет ни каких хэшей.

 

спор о том, что лучше PAL или SECAM

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

 

Предлагаю закончить обсуждение

Поддерживаю. ;)