Я хочу генерировать свой номер версии автоматически. В git я могу использовать
pkgver() {
cd local_repo
printf "%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}
Но как я мог сделать что-то подобное с ископаемыми? Я знаю, что мог бы использовать manifest.uuid, но он не может предоставить порядковый номер, подходящий для сравнения обновлений версий.
Я собираюсь проигнорировать нумерацию версий в стиле ###.###, потому что более полезным будет доступ к идентификатору, уникальному для всех проверок (даже между ветвями), и люди могут делать с ним все, что им заблагорассудится.
Простое число, которое вы можете легко получить, — это количество уникальных чекинов за всю историю проекта. Следующая команда предоставляет этот номер...
fossil info
Ради демонстрации я клонировал репозиторий ископаемого-scm, чтобы узнать количество чекинов...
project-name: Fossil
repository: /home/faculty/xxxx/fossil_repos/fossil-scm/../fossil-scm.fossil
local-root: /home/faculty/xxxx/fossil_repos/fossil-scm/
config-db: /home/faculty/xxxx/.fossil
project-code: CE59BB9F186226D80E49D1FA2DB29F935CCA0333
checkout: d3b2dabaa5eb64e1f73595bbe9e42d9586d5ac9e 2014-02-28 20:00:02 UTC
parent: 3d7eaeda866cc831d59abe2b1ddf15184aa14c4a 2014-02-28 19:31:38 UTC
tags: trunk
comment: re-generate other makefiles (user: jan.nijtmans)
checkins: 6713
Я бы извлек это значение одним из двух способов. Во-первых, если у вас есть grep с расширением Perl ("-P")...
fossil info | grep -oP 'checkins:\s*\K\d+'
Не все установки grep поддерживают это (университет, в котором я преподаю, поддерживает это расширение только на большинстве систем), поэтому вместо этого вы можете использовать sed (в приведенном ниже примере используется GNU sed)...
fossil info | sed -n 's/checkins:[ \t]*//p'
В любом случае, для приведенного выше примера вывода каждая команда предоставит...
6713
Кроме того, чтобы высказать свои мысли, мне не очень нравится идея получать номера версии/сборки продукта от вашего SCM. Роль SCM должна заключаться в отслеживании версий кода продукта и других артефактов. Добавление окаменелого или гит-кода к вашему продукту связывает исходный код с его SCM, пусть даже немного. Так что позже, когда вы поумнеете и решите сменить SCM (такое бывает, правда?), вы потеряете свой старый механизм нумерации версий для другого... но не потому, что механизм нумерации в вашем коде был неудовлетворительным.
Кроме того, одна из причин, по которой я использую ископаемое, заключается в том, что оно позволяет членам моей команды использовать разные SCM для своей удаленной разработки, поскольку ископаемое изначально поддерживает git и может без особых трудностей поддерживать другие SCM (как это сделала NetBSD с ископаемым/CVS). В такой среде разработки никто не хочет, чтобы код сочетался с одним SCM.
Во всяком случае... только мои пять копеек.
Удачи.
Я бы посоветовал рассматривать номер версии с точками как маркетинговый артефакт. С тем же успехом это может быть кодовое имя, цвет или что-то еще, что позволяет быстро идентифицировать общедоступную сборку. Но есть преимущества в использовании имен, которые достаточно короткие, чтобы люди могли их запомнить, и которые также указывают на какой-то естественный порядок, чтобы люди сразу знали, что «kitkat» новее, чем «jellybean».
Добиться, чтобы ваша система контроля версий обеспечивала это каким-либо автоматизированным способом — это рецепт головной боли. А с распределенной системой управления версиями возникает дополнительная проблема, заключающаяся в том, что разным версиям может быть присвоено одно и то же имя, если они создаются в разных местах разными разработчиками и, вероятно, с разными параметрами. Вы даже не можете использовать количество сборок, потому что разные разработчики будут выполнять сборку в разное время.
Если все «официальные» сборки создаются в одной системе, вы можете использовать автоматизацию в этой системе, чтобы присвоить каждой такой сборке уникальные имена. Но как насчет портативного приложения, созданного для многих платформ, и в этом случае, вероятно, созданного на многих разных машинах?
ИМХО, единственный разумный выход - признать, что номер версии совершенно произвольный и искусственный для системы сборки.
Конечно, с точки зрения управления проектом вам необходимо иметь политику создания и назначения номеров версий и тщательно следовать этой политике.
В fossil одним из подходов к управлению этим является создание ветки для каждого общедоступного выпуска. В качестве одной из первых проверок в этой ветке вы меняете номер версии, отображаемый в документации, и код, чтобы он соответствовал, возможно, включая дополнительный квалификатор, такой как «альфа», «бета» или «кандидат на выпуск». По мере прохождения цикла релиза найденные ошибки могут быть исправлены в этой ветке. Между тем, функции, не запланированные к выпуску, могут разрабатываться в своих собственных ветках и/или на магистрали без риска прерывания процесса выпуска. Естественно, как только релиз сделан, его можно и, вероятно, нужно объединить обратно в основную часть, чтобы ни одно из исправлений ошибок не потерялось.
Но не закрывайте эту ветку, это дает вам логическую основу для будущего обслуживания этой выпущенной версии, позволяя легко проверить исходный код, который был основой для окончательного выпуска этой версии.
Независимо от того, была ли сохранена ветвь или нет, важно включить достаточно UUID манифеста, чтобы определить, какая проверка была фактически выпущена в самом выпуске. Это может означать, что на практике никогда не следует создавать выпуск в ископаемом рабочем пространстве с какими-либо ожидающими изменениями.
Поскольку я допустил эту ошибку в своем собственном проекте, я добавил код в процесс сборки проекта, который проверяет чистоту рабочей области, а если нет, отображает громкие предупреждения и заставляет номер версии, отображаемый встроенным кодом, говорить, что сборка также не является безопасным для выпуска. Процесс также предоставляет компилятору первые несколько цифр UUID через параметр командной строки, такой как -DUUID=[0123456789]. Этот трюк был выполнен с использованием fossil changes для обнаружения грязного рабочего пространства и файла manifest.uuid для предоставления UUID. UUID также можно получить от fossil info.
Makefile верхнего уровня моего проекта включает следующий код:
#
# Discover fossil checkin id and public version number
#
MANIFESTUUID := $(shell sed -e "s/\(.\{10\}\).*/\1/" manifest.uuid)
VERSIONMAJ := $(shell sed -n -e "/define VERSION_MAJ/ s/^[^0-9]*\([0-9]*\)[^0-9]*$$/\1/p" src/version.h)
VERSIONMIN := $(shell sed -n -e "/define VERSION_MIN/ s/^[^0-9]*\([0-9]*\)[^0-9]*$$/\1/p" src/version.h)
VERSIONPAT := $(shell sed -n -e "/define VERSION_PAT/ s/^[^0-9]*\([0-9]*\)[^0-9]*$$/\1/p" src/version.h)
CHECKCLEAN := $(if $(shell fossil changes),-WITH-UNCOMMITTED-CHANGES)
#
# Create a filename-friendly version string like v1.123p42 where
# exacly three digits of the minor version number are displayed.
#
VERSION := v$(VERSIONMAJ).$(shell echo 000$(VERSIONMIN) | sed -n -e s/^.*\([0-9]\{3\}\).*$$/\1/p )p$(VERSIONPAT)$(CHECKCLEAN)
Это зависит от двух файлов в ископаемом рабочем пространстве и от выходных данных команды fossil changes для создания строки, которая может использоваться как часть имени файла выпущенного пакета, включая старший номер, младший номер, уровень исправления, и если рабочее пространство недостаточно чистое, лишний текст -WITH-UNCOMMITTED-CHANGES. Он также помещает первые 10 символов UUID в переменную MANIFESTUUID, откуда его можно передать в компиляцию.
В соответствии с политикой основная, второстепенная и исправленная части номера версии хранятся в файле src/version.h и время от времени изменяются по мере выполнения работы.
