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!
