[devel] Обновление пакета из upstream на примере pybind11

[Ivan A. Melnikov]

On Thu, Jul 27, 2023 at 12:11:35PM +0300, Dmitry V. Levin wrote:
> On Thu, Jul 27, 2023 at 10:58:24AM +0300, Nikolai Kostrigin wrote:
> [...]
> > > Как я понимаю, проблема в том, что у апстрима
> > > несколько "стабильных" веток, среди которых
> > > v2.9 (из которой пакет собран сейчас)
> > > и v2.11 (из которой мы хотим собрать пакет),
> > > и эти ветки друг от друга не наследуют. Соответсвенно,
> > > нужно переехать с одной апстримной ветки на другую.
> [...]
> > Сейчас стало понятно, что это был не единичный случай.
> > Раз уж это вынесено на публичное обсуждение, приглашаю остальных 
> > мэнтейнеров высказать свое мнение при желании.
> 
> Предлагаю поинтересоваться у апстрима, зачем они так делают.
> Может быть, они не в курсе, как это принято.

Мне кажется, именно так и принято: в момент
релиза мажорной версии форкается release branch, и далше
туда добавляются коммиты c улучшениями/исправлениями этого
релиза, и выходят минорные выпуски (ну или patch-выпуски,
если минорной считать вторую цифру). Такие выпуски
на разных ветках имеют общего предка, но напрямую
друг от друга не наследуют.

То же самое я вижу и в стабильном ядре, и в glibc, и
в gcc, и вообще много где. Кстати, интересно, что у нас
эти три пакета переходят на новые ветки по-разному:

kernel-image-un-def ребейзится (по крайней мере
переход 6.3->6.4 был таким) и преодолевает проверку
наследования

glibc мерджится

gcc вообще собирается в новый пакет =)

> Например, git.git на момент
> последнего фикса поддерживал 11 релизных веток, и отношение наследования
> там строго соблюдено.

В git.git что-то другое?

-- 
  wbr,
    iv m.