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

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

ps ну вот мне не понятно что было раньше... например 2017-02-03 или 2017-03-02? И во вторых.... как по db74878 найти в гите 734713bc047d87bf7eac9674765ae793478c50d3?
в 3-их: у пользователя (или у наладчика на флешке) есть две сборки "(2017-02-03 db74878)" и "(2017-02-03 df56a87)" - какая свежея?

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

А как вы в оффлайне определяете такое написание? Например на сроке годности продуктов?
в readme проекта можно указать формат интерпретации даты yyyy-dd-mm или yyyy-mm-dd - для новых
участников проекта. Там же можно указать и стили оформления кода и т.п.

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

Два варианта:
1) выводить в переменную и время. для избегания разночтений - в UTC.
2) в логе git посмотреть полную дату-время коммитов.
Контроль версий, как и баэкапы можно не любить, но жизнь вынуждает их применять... рано или поздно.

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

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

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

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

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

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

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


Сообщение отредактировал johnshadow - Feb 7 2017, 09:44

Давайте отделим мух от котлет. Я свой код контролирую либо с помощью 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 сами найдете нужный релиз и нужный срез. тогда вопрос - зачем пихать в ПО этот жуткий хэш? Как говориться: в чем профит?

Так ведь в распределенных СКВ нет возможности проводить сквозную нумерацию билдов\коммитов.
Допустим я создал ветку от вашего проекта и работаю с ней, параллельно с вами.
У меня свои номера билдов теперь, у вас свои. И как их дальше сравнивать?
На mercurial пытались прикрутить сквозную нумерацию, но по моему это отход от идеологии распределенных СКВ.
А так как есть дата коммита, то полный hash для однозначного определения конкретного коммита и не нужен.

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

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

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

Вот где у нас идеологическая разница - у меня в master попадает только проверенный код, который прошел
тестирование в том числе и на группе реальных устройств у клиентов (которые согласились стать бета-тестерами). Таким образом в любой
момент из master всегда можно собрать "стабильный" релиз. И как у релизов, так и у бета-сборок
однотипный вывод версии - типа "XX.YY дата коммита и короткий hash". Где XX.YY это мажорные и минорные значения версии,
которые правятся руками (может быть и тэгом и git).
В вашем же случае, если возникает необходимость проверить бету на оборудовании клиента, но клиент столкнется с двумя разными стилями указания версии:
1) Релизная, вида: "XX.YY.buil_num"
2) Бета, вида: "commit_hash" или что-то подобное
Т.е. имеем две сущности (два вида), хотя фактически можно обойтись одной: только второй, так как первая не может быть универсальной,
ведь она поддерживается только в master ветке. Стоит ли плодить сущности без их необходимости?

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

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

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

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