Jump to content

    
Sign in to follow this  
kostya-m

Вопрос по лицензированию

Recommended Posts

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

спор о том, что лучше 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

Share this post


Link to post
Share on other sites
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:

 

Share this post


Link to post
Share on other sites
А как вы в оффлайне определяете такое написание? Например на сроке годности продуктов?
Ни как. На продуктах пишут 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, в нотепад++ версия и время сборки.... во всех программах версия/сборка/время сборки.... привязки к номерам ревизий из СКВ не встречал.... хотя не значит что их нет, и не значит, что это плохой способ... просто мне удобней автобилдом контролировать номера релизов.

post-49045-1486455038_thumb.png

Share this post


Link to post
Share on other sites
просто мне удобней автобилдом контролировать номера релизов.

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

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

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

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

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

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

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

Edited by johnshadow

Share this post


Link to post
Share on other sites
Как без систем контроля версии выполняете модификацию кода?

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

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

Share this post


Link to post
Share on other sites
Как говориться: в чем профит?

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

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

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

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

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

 

 

Share this post


Link to post
Share on other sites
У меня свои номера билдов теперь, у вас свои. И как их дальше сравнивать?

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

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

 

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

 

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

Share this post


Link to post
Share on other sites
все сливается в основной ствол, тестится в основном стволе.

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

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

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

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

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

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this