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 день, то есть встроеный механизм - , ну или в схему добавить время. -- Best regards!
Re: Создание бекпорта, как выбрать версию?
я встречал такую практику: 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, помнить про всякие тильды и прочее
Re: Создание бекпорта, как выбрать версию?
On 2015-10-28, Oleksandr Gavenko wrote: > Я буду делать пакетпроивание с master, которому еще не назначена версия. > > Какое имя давать, когда апстрим *еще не зафиксировал* версию? Интересно что бы > свежак перезатер мой пакет во время соотвествующего будущего обновления. > Пока я вижу что 0.3.0+master работает: user@desktop ~/devel/sigrok/libsigrok == bash# dpkg --compare-versions 0.3.0-1 lt 0.3.0+master && echo ok || echo fail ok user@desktop ~/devel/sigrok/libsigrok == bash# dpkg --compare-versions 0.3.1~bpo8-1 lt 0.3.0+master && echo ok || echo fail fail user@desktop ~/devel/sigrok/libsigrok == bash# dpkg --compare-versions 0.3.1 lt 0.3.0+master && echo ok || echo fail fail Правила сравнения версий описан в полиси: 5.6.12.`Version' First the initial part of each string consisting entirely of non-digit characters is determined. These two parts (one of which may be empty) are compared lexically. У меня будет "+master", у пакетов с исправлениями старой версии на подобии 0.3.0-5, т.е. пустая строка и я выигрываю. Еще также сработает любая alpha и '.', но с '+' прикольней выглядит. > Правильно что если бы была свежая устраивающая меня версия, например 0.3.1, то > я бы назвал ее 0.3.1~bpo8-1? > Кажется так, судя по описанию в https://wiki.debian.org/BuildingFormalBackports -- Best regards!
Создание бекпорта, как выбрать версию?
Реальный прмер, имеем: $ rmadison libsigrok2 libsigrok2 | 0.3.0-1 | stable | amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x libsigrok2 | 0.3.0-1 | testing| amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x libsigrok2 | 0.3.0-1 | unstable | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x $ git log --graph --all --decorate --oneline git log --graph --decorate --simplify-by-decoration --oneline --all * 211cc97 (HEAD -> master, origin/master, origin/HEAD) tests: Drop another obsolete sr_analog_float_to_string() test. | * 8f54ac8 (tag: libsigrok-0.3.0, origin/libsigrok-0.3.x) Doxyfile/Doxyfile_internal: Bump version number to 0.3.0. |/ | * f1b296f (origin/dslogic) Code drop from DreamSourceLabs first source release. | | * 6f95fee (tag: libsigrok-0.2.2, origin/libsigrok-0.2.x) Doxyfile: Set version to 0.2.2. | |/ |/| * | f6b5969 (tag: libsigrok-0.2.1) Bump package version to 0.2.1, libtool version to 1:1:0. * | 26aec7f (tag: libsigrok-0.2.0) Drop link-mso19/nexus-osciprime in preparation for release. |/ * 7e41e31 (tag: libsigrok-0.1.1) sr: fx2lafw: Forgot to add (C) line to fx2lafw.h in recent commit. * fefd54a (tag: libsigrok-0.1.0) sr: Initial 0.1.0 release. * a1bb33a Start of code base layout restructuring. Поддержку для моего устройства добавили после 0.3.0. Я буду делать пакетпроивание с master, которому еще не назначена версия. Какое имя давать, когда апстрим *еще не зафиксировал* версию? Интересно что бы свежак перезатер мой пакет во время соотвествующего будущего обновления. Правильно что если бы была свежая устраивающая меня версия, например 0.3.1, то я бы назвал ее 0.3.1~bpo8-1? Где полиси по бекпортам? Я наткнулся на частный анонс http://backports.debian.org/news/jessie_released_-_backports_related_changes/ но грепать мейлисты и мониторить RSS/Atom для одноразового случая некошерно. Если я делаю для себя - значит мне не нужно следовать именованию backports, какой принцип позволяет последующие обновления? -- Best regards!
