Автоматическое проставление версии билда

[SASA]

http://www.prog.org.ru/topic_5495_0.html

[SABROG]

Вопрос к знатокам pro-файлов - попробуйте решить эту же задачу с QMake.

Qt уже использует perl при сборке, так что пихайте скрипт в target.commands или если нужен вызов на этапе создания makefile'ов, то типа такого:

Код:

MYVAR = $$system(perl ...)

[mks56]

Может немного не в тему, но при использовании в Win в качестве средства контроля версий связки Subversion+TortoiseSVN в составе последней есть утилита SubVCRev, которая как раз для этого и предназначена. Правда, в качестве номера будет ревизия Subversion.

[SABROG]

Можно сделать как это делает Qt с qmake. Написать консольную утилиту, которая делает всю черную работу. В .pro файле искать готовый исполнимый файл этой утилиты, если её нет, то из исходников сначала собирается эта утилита, затем вызов подставляется в makefile'ы. В момент сборки сначала идет вызов этой утилиты, затем собираются исходники проекта.

Только всё это ерунда. Я не могу вспомнить ни одной программы в исходниках которой был инкремент версии. И это правильно. Просто подумайте, вы скачали исходники Qt 4.6.2, сделали configure, а в заголовке какого-нибудь QtDesigner'a у вас стоит версия Qt 4.6.3, а если сделаете еще раз перекомпиляцию, то будет 4.6.4 и т.д. За версиями должен следить разработчик и коду, который увеличивает версию нечего делать в исходниках проекта, которые распространяются для других людей. Если это действительно нужно, то должно быть 2 .pro/CMakeList.txt файла, один публичный, другой приватный.

[crackedmind]

Пример с Qt какой то странный. Зачем при каждом билде увеличивать patch version? Есть же много софта у которого 4х значный номер версий например 1.1.2.2056 И иногда бывает что удобнее выпустить версию 1.1.2.2057 с багфиксом серъезной ошибки , нежели обзывать ее 1.1.3.

[lit-uriy]

И иногда бывает что удобнее выпустить версию 1.1.2.2057 с багфиксом серъезной ошибки , нежели обзывать ее 1.1.3.

У меня несколько вопросов:
1) Что означает 3 цифра?
2) Для кого удобнее?
3) Почему удобнее?

[SABROG]

Не согласен, это какой-то хаос с версиями будет. Всё равно что выпускать новую версию программы на каждый чих. "А что нового в новой версии?" - "Ничего, отступы п$оправил..."

Думаю лучше придерживаться GNU version scheme.

[SASA]

Основную версию надо прописывать руками (неапример 3.2). Но в скомпилированный проект должен попасть номер, который однозначно ассоциируется с исходниками. Щёлкаешь "О программе" и видишь 3.2.23213. Удобно для поддержки. У нас в проекте 23213 - это номер ревизи в SVN.
как это можно сделать - http://www.prog.org.ru/topic_5495_0.html

[ufna]

Хз, я давным-давно для этих целей написал микропрогу, которую среда запускает после успешного билда. Она правит .rc и радуется жизни. Ну, приходится для среды настраивать post-build event, ну и черт с ним как бы.

[crackedmind]

1) Что означает 3 цифра?

А  что непонятного?
1 - major version
2 - minor version
3 - patch version
4 - build version

[lit-uriy]

4 - build version

Я вот и не понимаю зачем номер сборки, что полный бардак в конторе? Каждая пара "make clean" + "make" приводит к разным результатам работы программы?

Щёлкаешь "О программе" и видишь 3.2.23213. Удобно для поддержки. У нас в проекте 23213 - это номер ревизи в SVN.

Опять бардаком пахнет.
Я вот получаю от пользователя, например,  "Программа 3.2.1", лезу в гит и смотрю соответствующую метку (tag) или в SVN, тоже самое, только там это каталог отдельный.
У меня пара "make clean" + "make" на одной и той же версии, даёт один и тот же результат. И по другому быть не может

[igor_bogomolov]

Считать количество компиляций, на мой взгляд, действительно бессмысленно. Тем более при совместной разработке. А вот иметь возможность идентифицировать, на основе какой ревизии или коммита базируется программа, очень удобно. Так что в чем бардак, не понимаю.
Я например делаю так.

Код

Bash
static char Version[]   = \"0.1.8\";
static char BuildData[] = \"$(git log -1 --pretty="%ai %h" | awk '{ print $1 }')\";
static char Revision[]  = \"$(git log -1 --pretty="%ai %h" | awk '{ print $4 }')\";

[crackedmind]

lit-uriy
В рамках выпуска версии "3.2.1" можно сделать несколько билдов, в каждом из которых может быть исправления или добавления чего то. Попасть к пользователю случайно может любая из них. Как ты будешь идентифицировать в каком из билдов была допущена ошибка?

Билд инфа для разработчиков чтоб удобнее было искать ошибку.

Если следовать твоей логики многие конторы ошибаются что идентифицируют версии программ по билдам))

[lit-uriy]

lit-uriy
В рамках выпуска версии "3.2.1" можно сделать несколько билдов, в каждом из которых может быть исправления или добавления чего то.

Как такое может быть?
Исправления отмечаются строго третьей цифрой
Минорные добавления - второй
Одновременно исправления и минорные добавления - второй.

Если следовать твоей логики многие конторы ошибаются что идентифицируют версии программ по билдам))

Совершенно верно. Это надёжный признак не надёжной разработки

Попасть к пользователю случайно может любая из них.

Это я вообще не понял, как к пользователю случайно может попасть конечный продукт?

[frostyland]

Хмм.
А как в Qt проставляются версии надстроек, к примеру?
Что-то я не помню в описании создания плагинов какихто танцев с бубнами...

С уважением, ВВК