Re: Создание бекпорта, как выбрать версию?
On 2015-10-28, dimas wrote:
> я встречал такую практику:
> x.y.z+git123abcd
> и такую
> x.y.z+git2001-12-31
> с одной стороны, номера коммитов в git случайны и не последовательны, т.е. по
> голому хэшу никак не понять, что коммит 26aec7f, скажем, новее коммита fefd54a.
> хотя если цель собрать одну конкретную версию, да и то на время, то можно и так.
> вариант с датой однозначно определяет, какая версия новее, и, на мой взгляд,
> выглядит куда информативнее (типа "слепок git от такого-то числа"), нежели хэш
> коммита, который через пять минут забудешь. с другой стороны, если собирать
> несколько разных коммитов, которые вышли в один день, то голой датой не
> отделаешься. но это актуально при активном тестировании там, для домашнего
> использования вряд ли.
> и я бы писал именно через "+". при выходе x.y.z+1 оная априори будет считаться
> более новой, и не надо парить голову, будет ли x.y.z-0 считаться новее
> x.y.z-git123, помнить про всякие тильды и прочее
>
Спасибо за ответ. Я вообще не знаком ни с какой практикой, к "+" пришел
медитацией над полиси по сравнению версий. Среди других допустимых не-alnum
символов только '.' тоже не участвует в специальных правилах, но '+' красивее
выглядит.
Идея с хешами провальна даже тем что цифро-буквы хешей не отражают прогрес
проекта (при сравнении версий по правилам dpkg).
Вот до идеи использовать дату как то не допер. Плюс очень нагляден маркер CVS:
git/hg/svn. Если публично распространять, то можно после даты и хеш засунуть и
стараться держать 2 параметра согласоваными.
А что до нескольких сборок в 1 день, то есть встроеный механизм -
<debian_revision>, ну или в схему добавить время.
--
Best regards!
Reply to: