Увеличивающий монотонность Номер версии на основе Подвижных Фиксаций
Когда я использовал подверсию для кода для приложения, я мог добавить период и результат svnversion к номеру версии, чтобы создать уникальный и увеличивающий монотонность номер версии и также быть гарантированными тот любой контроль того же пересмотра кода генерировал бы тот же номер версии.
В Подвижном, потому что числа пересмотра не обязательно последовательны через клоны, локальное число пересмотра не подходит. Хеш соответственно уникален и последователен, но не создает число, которое является увеличением монотонности. Как я могу генерировать подходящее число для добавления к номеру версии на основе Подвижных фиксаций репозитория?
править: У меня есть приложение, которое имеет автоматическое обновление, проверяющее, что это зависит от номера версии, который является цепочкой разделенных от периода целых чисел, чтобы определить, является ли версия более новой или нет. Это стало распространено, что во время между выпусками, у меня есть некоторые пользователи, испытывающие тестовые сборки. Часто, эти сборки решают проблему, которую имел тестер, таким образом, тестер прекращает использовать выпущенную версию и переключается на тестовую сборку. Мои исходные цели в добавлении дополнительного компонента к номеру версии были к:
- удостоверьтесь, что, когда выпуск произошел, тем, которые используют тестовую сборку, автоматически подарили обновление также
- смогите легко сказать, использовал ли тестер новую тестовую сборку
Например, эти 0.5.0 выпусков имели номер версии 0.5.0.410; прежде 0.5.1 был выпущен, были тестовые сборки с номерами версий 0.5.1.411, 0.5.1.420, и 0.5.1.421; затем, эти 0.5.1 выпусков имели номер версии 0.5.1.423.
3 ответа
Мне все еще нужно что-то, чтобы попытаться сохранить порядок и соответствие различных сборок разработки, я сначала попытался использовать временную метку unix последней фиксации:
REV=$(hg tip --template '{date|hgdate}' | cut -f1 -d' ')
Это, однако, досадно длинное (10 цифр). (И, конечно же, его уникальность не гарантируется, но в проекте, где я единственный разработчик, вероятность двух коммитов за одну секунду по существу равна 0; фактически, вероятность двух коммитов в течение 1 минуты после друг друга по существу равны 0.)
Поскольку «базовый» номер версии (часть, к которой добавляется этот номер версии) изменяется только сразу после выпуска с тегами, в итоге я использовал количество минут между подсказкой и последним помеченным предком. :
HG_LAST_TAG_TIMESTAMP=$(hg log -r "$(hg log -r '.' --template '{latesttag}')" --template "{date|hgdate}\n" | cut -f1 -d' ')
HG_TIP_TIMESTAMP=$(hg log -r '.' --template "{date|hgdate}\n" | cut -f1 -d' ')
REV=$(( ($HG_TIP_TIMESTAMP - $HG_LAST_TAG_TIMESTAMP) / 60 ))
( edit : использование подсказки было ошибкой, так как это относится к последней фиксации в любой ветке; использование log -r '.' относится к ревизии, на которой основана рабочая копия.)
Как сказал @Matthew , нельзя ожидать, что какое-либо сравнение между номерами версий клонов будет иметь какое-либо значение. Однако, если вы основываете свое приложение на одном репозитории и всегда возвращаетесь в этот центральный репозиторий из любых клонов, вы можете полагаться на этот единственный центральный номер версии, пока вы придерживаетесь одной ветки.
По сути, если вы используете Mercurial таким образом, чтобы имитировать Subversion, то есть с одним центральным репозиторием, вы можете использовать номер версии в качестве маркера в сборках вашего приложения.
Надеюсь, это поможет.
Вы попали в самую точку. Использование любого монотонно увеличивающегося номера локальной версии может конфликтовать с распределенной природой. Это фундаментальное дизайнерское решение не может быть элегантным способом обойтись.