История изменений

по-моему я вобщем все понимаю, но, допустим, что нет.

Видимо, с твоей точки зрения надо вернуться к старой модели, когда в стабильной ветки были только багфиксы, а новый релиз надо было ждать 4-6 лет (как это было с 2.8 и 2.10).

стоп-стоп-стоп! во-первых, хотя это наименее важный вопрос, что изменилось, начиная с 2.10? мы ждем следующих релиз гораздо раньше? когда? позволит ли это уйти от реального версионирования по слепкам а-ля git~20181204?

во-вторых, бампинг версий GEGL&babl был всегда и это совершенно никак не ускорило выход 2.6, 2.8 и 2.10.

в-третьих, то, что нужно девелопить gegl&babl не объясняет, почему для этого нужно брать тулчей чуть ли не из git.

в-четвертых, я готов признать справедливым, что разработчики gimp не хотят иметь стабильный api для gegl&babl, потому что gimp такой быстроразвивающийся (ха-ха) проект. готов признать, что это действительно их дело, но при одном условии. хорошо, объедините тогда для нас, пользователей, ваши низкоуровневые библиотеки gimp с самим gimp (потому что нам нет никакого дела, как вы это там разрабатываете и насколько стабильный ваш внутренний api) и дайте возможно собирать гимп на якобы целевой платформе! (я уж не говорю про план Б: сначала соберите статический билд для Linux, а потом уже для Windows). за каким хреном вы так дерзко поступаете с внешними зависимостями и тулчейном??! вашему gegl&babl так уж необходим glib2 последней версии? я это могу объяснить только хипстерской прытью одного из девелоперов, который спешит опробовать фишечки нового c++ стандарта, а glib2 бампит потому что сидит на федоре.

по-моему я вобщем все понимаю, но, допустим, что нет.

Видимо, с твоей точки зрения надо вернуться к старой модели, когда в стабильной ветки были только багфиксы, а новый релиз надо было ждать 4-6 лет (как это было с 2.8 и 2.10).

стоп-стоп-стоп! во-первых, хотя это наименее важный вопрос, что изменилось, начиная с 2.10? мы ждем следующих релиз гораздо раньше? когда? позволит ли это уйти от реального версионирования по слепкам а-ля git~20181204?

во-вторых, бампинг версий GEGL&babl был всегда и это совершенно никак не ускорило выход 2.6, 2.8 и 2.10.

в-третьих, то, что нужно девелопить gegl&babl не объясняет, почему для этого нужно брать тулчей чуть ли не из git.

в-четвертых, я готов признать справедливым, что разработчики gimp не хотят иметь стабильный api для gegl&babl, потому что gimp такой быстроразвивающийся (ха-ха) проект. готов признать, что это действительно их дело, но при одном условии. хорошо, объедините тогда для нас, пользователей, ваши низкоуровневые библиотеки gimp с самим gimp (потому что нам нет никакого дела, как вы это там разрабатываете и насколько стабильный ваш внутренний api) и дайте возможно собирать гимп на якобы целевой платформе! (я уж не говорю про план Б: сначала соберите статический билд для Linux, а потом уже для Windows). за каким хреном вы так дерзко поступаете с внешними зависимостями и тулчейном??! вашему gegl&babl так уж необходим glib2 последней версии? я это могу объяснить только хипстерской прытью кого-нибудь из девелоперов, кто спешит опробовать фишечки нового c++ стандарта, а glib2 бампит потому что сидит на федоре.

по-моему я вобщем все понимаю, но, допустим, что нет.

Видимо, с твоей точки зрения надо вернуться к старой модели, когда в стабильной ветки были только багфиксы, а новый релиз надо было ждать 4-6 лет (как это было с 2.8 и 2.10).

стоп-стоп-стоп! во-первых, хотя это наименее важный вопрос, что изменилось, начиная с 2.10? мы ждем следующих релиз гораздо раньше? когда? позволит ли это уйти от реального версионирования по слепкам а-ля git~20181204?

во-вторых, бампинг версий GEGL&babl был всегда и это совершенно никак не ускорило выход 2.6, 2.8 и 2.10.

в-третьих, то, что нужно девелопить gegl&babl не объясняет, почему для этого нужно брать тулчей чуть ли не из git.

в-четвертых, я готов признать справедливым, что разработчики gimp не хотят иметь стабильный api для gegl&babl, потому что gimp такой быстроразвивающийся (ха-ха) проект. готов признать, что это действительно их дело, но при одном условии. хорошо, объедините тогда для нас, пользователей, ваши низкоуровневые библиотеки gimp с самим gimp (потому что нам нет никакого дела, как вы это там разрабатываете и насколько стабильный ваш внутренний api) и дайте возможно собирать гимп на якобы целевой платформе! (я уж не говорю про план Б: возьмите ж*пу в охапку и соберите статический билд сначала для Linux, а потом уже для Windows). за каким хреном вы так дерзко поступаете с внешними зависимостями и тулчейном??! вашему gegl&babl так уж необходим glib2 последней версии? я это могу объяснить только хипстерской прытью кого-нибудь из девелоперов, кто спешит опробовать фишечки нового c++ стандарта, а glib2 бампит потому что сидит на федоре.

по-моему я вобщем все понимаю, но, допустим, что нет.

Видимо, с твоей точки зрения надо вернуться к старой модели, когда в стабильной ветки были только багфиксы, а новый релиз надо было ждать 4-6 лет (как это было с 2.8 и 2.10).

стоп-стоп-стоп! во-первых, хотя это наименее важный вопрос, что изменилось, начиная с 2.10? мы ждем следующих релиз гораздо раньше? когда? позволит ли это уйти от реального версионирования по слепкам а-ля git~20181204?

во-вторых, бампинг версий GEGL&babl был всегда и это совершенно никак не ускорило выход 2.6, 2.8 и 2.10.

в-третьих, то, что нужно девелопить gegl&babl не объясняет, почему для этого нужно брать тулчей чуть ли не из git.

в-четвертых, я готов признать справедливым, что разработчики gimp не хотят иметь стабильный api для gegl&babl, потому что gimp такой быстроразвивающийся (ха-ха) проект. готов признать, что это действительно их дело, но при одном условии. хорошо, объедините тогда для нас, пользователей, ваши низкоуровневые библиотеки gimp с самим gimp (потому что нам нет никакого дела, как вы это там разрабатываете и насколько стабильный ваш внутренний api) и дайте возможно собирать гимп на якобы целевой платформе! за каким хреном вы так дерзко поступаете с внешними зависимостями и тулчейном??! вашему gegl&babl так уж необходим glib2 последней версии? я это могу объяснить только хипстерской прытью кого-нибудь из девелоперов, кто спешит опробовать фишечки нового c++ стандарта, а glib2 бампит потому что сидит на федоре.