Здравствуйте, Miroff, Вы писали:
M> Единственное, хоть сколько-то разумное решение это выделить общий код в отдельный продукт с собственным циклом релизов и собственными разработчиками.
Обычно это первый шаг к провалу. Команда, которая занимается общим кодом очень быстро перестает понимать за чем этот общий код нужен, и улетает в космос от реальных проблем. Правильно расставить приоритеты по фичам такая команда тоже не может, у нее просто данных нет.
В такой ситуации спасает либо "inner source" — у общего сервиса есть владелец от бизнеса, но остальные могут в него контрибутить, если горит. Но только через пул-реквесты и ревъю изменений от владельца. Либо менеджерская обвязка у такой команды в виде матерого продакта, програм-менеджера и прочих людей, которые приносят понимание за чем этот продукт нужен, и выравнивают его по реальным бизнес-требованиям. На практике, второй вариант требует особенной дисциплины от всех участников и в живой природе встречается довольно редко.
vsb>А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.
Начиная с определенного размера средств для работы с такими репозиториями становится маловато. Распределенные кэширующие билд-системы, опять же, надо уметь настроить, и тратиться на их поддержку. В общем, довольно тяжелая инфра.
Ну и в монорепо всегда что-то где-то сломано. Нет даже самого понятия stable release.
Здравствуйте, Barbar1an, Вы писали:
B>как вообще это делается?
B>ну предположим компания очень крупная и у нее 100500 проектов, и которые ессно обязательно испольщзуют общие компоненты B>как такое версионится?
Честно говоря, я не очень верю что один и тот же код может развиваться двумя разными командами.
То есть на практике я такого не видел, но возможно есть варианты, да и я вообще мало чего видел.
Но на мой взгляд, обычно код контролируется одной командой, "общий код" = "бесхозный код" — не должно такого быть imho.
На базе гита внесение нужной правки в "чужой" код можно организовать pull request например из другой команды,
такой механизм любая более-менее современная система управления кодом предоставит.
Если код оформлен в виде библиотеки, ну там nuget/npm модуля это уже другой случай, все равно что использовать 3rd-party библиотеку.
То есть, имеем тогда общий код в виде отдельного "продукта" и его собственного репозитория.
Но тут еще зависит от используемой платформы и какого рода "модули" она поддерживает.
Я в том смысле, многие поддерживают локальные (внутри компании) репозитории для модулей типа npm или там nuget.
Здравствуйте, Miroff, Вы писали:
M>Я не встречал чтобы из идеи разделять общий код между командами хоть раз вышло что-нибудь хорошее.
Это отличное решение при условии что тебе не нужны независимые релизы отдельных частей. Потому что раскидывание по репам это дорого, очень дорого и для программеров и для девопсов.
Здравствуйте, vsb, Вы писали:
vsb>А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.
И в чем профит такого подхода? Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск. А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного.
Здравствуйте, Miroff, Вы писали:
vsb>>А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.
M>И в чем профит такого подхода?
В том, что нет возни с версиями, версия всегда ровно одна — последняя. И это предположительно убирает огромный пласт проблем по возне с совместимостью в каждой библиотечке. Ибо когда в каждом компоненте своя версия, есть транзитивные зависимости вроде того, что один старый компонент зависит от другого старого компонента, нужны какие-то багфиксы, и это всё превратится в ад по поддержке всех версий одновременно, ибо пользователи библиотек обновляться не хотят, им и так норм.
А когда версия одна — если хочешь что-то сломать — будь добр, пофикси всех клиентов в том же коммите. Не хочешь фиксить — значит и ломать не очень хочется.
M>Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск.
Это не минусы, с большими репозиториями работают не так, у гита есть специальные расширения для решения этой проблемы.
M>А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного.
Ну у гугла, микрософта, фейсбука, твиттера, юбера, эйрбнб получается, это из того, что я знаю. Понятно, что такая модель разработки требует адаптации команд и готовности делать (и принимать) пул-реквесты в чужие проекты.
Моё имхо — монорепо это маст хэв для маленьких проектов (условно до 3 команд по 10 человек). Начиная с некоего среднего размера уже можно переходить на репозиторий для каждого компонента, т.к. всё ещё не такое большое, чтобы вызвать существенные проблемы с версиями, можно заставлять остальные проекты переходить на последние версии в разумное время и снимать их с поддержки. И начиная с некоего большого размера можно переходить назад на монорепо, уже в другом виде и с другими инструментами, т.к. когда в компании 1000 команд, с ними всеми уже общий язык находить будет маловероятно, в итоге либо всё превратится в болото, где нельзя сделать никакое изменение, либо людям даётся возможность сделать это своё изменение и пофиксить самостоятельно всех остальных.
У каждой компании свой колхоз. Почти всегда этот колхоз работает только на жестко контролируемой виртуалке, на которой, собственно, и ведется разработка. Компьютеры, которые дают сотрудникаам, очень часто есть просто монитор для терминала этого сервера. Вся разработка — удаленно.
S>1) Имел в виду пример вот этого -- "Распределенные кэширующие билд-системы"?
Bazel, buck, прочие аналоги. Сами по себе инструменты простейшие, сложность живет в том, чтобы их хоть как-то надежно использовать.
Идея очень простая: есть большое хранилище, где лежат ответы на вопросы "дай мне скомпилированный файл с таким-то хешом". В твоем репо ты меняешь 1-2 файла, компилируешь только их, остальные миллионы просто скачиваются в готовом виде из того хранилища. После того как ты скомпилировал свои 1-2 файла, результат компиляции складывается туда же, в хранилище (его зовут CAS, content addressable storage).
По сути это получается этакая мемоизация всех компиляций. Хорошо работает для тормозных компиляторов типа С++. Плохо работает для быстрых, типа Erlang, где скомпилировать бывает быстрее, чем вытащить по сети.
Здравствуйте, Barbar1an, Вы писали:
B>ну например в гите. код разбивается на продукты, у каждого продукта свой репо, а общий код референсится через сабмодули?
Можно выносить в отдельные либы и через пакетный менеджер вроде конана подтягивать как зависимость. Проблема тут очевидна, довольно длительный путь интеграции изменений в общую часть т.к. надо со всеми договориться и пройти все тесты, потом миграция с тестированием новой версии либы во все продукты. Если компания очень крупная, то сможет себе позволить, наверное. С CI/DI будет полегче, но оно не панацея конечно же.
R>В идеале: Однако, единственная работающая идеально схема — это когда каждая новая версия библиотеки обеспечивает вплоть до бинарной совместимости со всеми предыдущими версиями, пока они используются. Т.е. что-то типа libc/libstdc++, когда все символы версионированы и новая функциональность выпускается с символами под новыми версиями
Без шансов, можно даже не пытаться. Слишком сложно научить среднего разработчика. И в тестировании тот еще ад.
Здравствуйте, vsb, Вы писали:
НС>>Это уже не просто про репы. Это, буквально, означает возможность только больших релизов всего сразу. С такими идеями во многих конторах тебя сразу пошлют, без разговоров. vsb>Релизы делаются постоянно и непрерывно.
Ты не сможешь делать постоянно и непрерывно релизы продукта, в который вовлечено большое количество команд, целиком.
НС>>Это у гугла то с его любовью к микросервисам получается огромный реп? vsb>Да.
ну предположим компания очень крупная и у нее 100500 проектов, и которые ессно обязательно испольщзуют общие компоненты
как такое версионится?
ну например в гите. код разбивается на продукты, у каждого продукта свой репо, а общий код референсится через сабмодули?
а другие варианты? бывают? особено такие которые както решают то что в разных проектах может редактироваться общий код который потом может быть сложно мержить
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
B>как вообще это делается?
B>ну предположим компания очень крупная и у нее 100500 проектов, и которые ессно обязательно испольщзуют общие компоненты B>как такое версионится? B>ну например в гите. код разбивается на продукты, у каждого продукта свой репо, а общий код референсится через сабмодули? B>а другие варианты? бывают? особено такие которые както решают то что в разных проектах может редактироваться общий код который потом может быть сложно мержить
В реальности: IMHO, либо нормальный пакетный менеджер, если все пишется на одном языке. Либо система сборки, реализующая функциональность пакетного менеджера. Плюс некая политика обратной совместимости, чтобы в одном exe'шнике не было 10-ти версий одной бибилиотеки с учетом транзитивных зависимостей.
Ну, либо серебряная пуля — микросервисы. Там, конечно, тоже нужно отслеживать зависимости, но одна из 2-х задач, которые решают микросервисы — обеспечить возможность работы разных команд независимо над общим проектом.
В идеале: Однако, единственная работающая идеально схема — это когда каждая новая версия библиотеки обеспечивает вплоть до бинарной совместимости со всеми предыдущими версиями, пока они используются. Т.е. что-то типа libc/libstdc++, когда все символы версионированы и новая функциональность выпускается с символами под новыми версиями. При этом в каждой сборке присутствуют все предыдущие версии функций (и любой старый бинарник будет работать с новой версией библиотеки). Т.е. каждая новая версия библиотеки содержит все предыдущие функции со старыми версиями + новую функциональность с новыми версиями. Если что-то уже не используется — оно удаляется. Однако, это сложнее реализовать, поэтому коммерсантами редко используется (дороже).
Здравствуйте, Barbar1an, Вы писали:
B>ну например в гите. код разбивается на продукты, у каждого продукта свой репо, а общий код референсится через сабмодули? B>а другие варианты? бывают? особено такие которые както решают то что в разных проектах может редактироваться общий код который потом может быть сложно мержить
Я не встречал чтобы из идеи разделять общий код между командами хоть раз вышло что-нибудь хорошее. Единственное, хоть сколько-то разумное решение это выделить общий код в отдельный продукт с собственным циклом релизов и собственными разработчиками. А в идеале еще и открыть его в open source.
Здравствуйте, Barbar1an, Вы писали:
B>как вообще это делается?
B>ну предположим компания очень крупная и у нее 100500 проектов, и которые ессно обязательно испольщзуют общие компоненты B>как такое версионится? B>ну например в гите. код разбивается на продукты, у каждого продукта свой репо, а общий код референсится через сабмодули? B>а другие варианты? бывают? особено такие которые както решают то что в разных проектах может редактироваться общий код который потом может быть сложно мержить
Очевидно, если компоненты самостоятельные то и должны поставляться как артефакты(модули).
т.е. к основному проекту подключили допустим dll определенной версии и с ней ведете разработку.
Если же используется общая кодовая база то тут как обычно — транк и бранч-фича в которой ведется разработка новой версии зависимости(модуля).
все это время фича синхронизируется с транком до готовности,
когда новая версия фичи готова вливаешь ее в транк. релизишь решение.
Тут главный обычно все решает и возможности системы контроля версий, языка программирования и его инструментов.
Здравствуйте, Miroff, Вы писали:
M> Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск.
Его чекаутят или селективно (нужное подмножество директорий) или лениво (подгружая / кэшируя по мере необходимости).
M> А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного.
Не очень понятно почему не можешь. Зависимость по исходникам (вместо зависимости по артефактам) — твой код собирается с текущей версией исходного кода другого проекта.
Здравствуйте, vsb, Вы писали:
vsb>В том, что нет возни с версиями, версия всегда ровно одна — последняя. И это предположительно убирает огромный пласт проблем по возне с совместимостью в каждой библиотечке. Ибо когда в каждом компоненте своя версия, есть транзитивные зависимости вроде того, что один старый компонент зависит от другого старого компонента, нужны какие-то багфиксы, и это всё превратится в ад по поддержке всех версий одновременно, ибо пользователи библиотек обновляться не хотят, им и так норм.
Если пользоваелям норм, то и не надо ничего менять. Сделали сервис, запустили в прод и он там крутится годами не останавливаясь. Зачем ему непременно обновлять библиотеки?
vsb>А когда версия одна — если хочешь что-то сломать — будь добр, пофикси всех клиентов в том же коммите. Не хочешь фиксить — значит и ломать не очень хочется.
А тестировать эти фиксы кто будет? Владелец библиотеки? Так у него в чужом коде компетенции нет, он не знает что там и почему. Владелец кода? А ему это зачем, у него свои планы по разработке,
внезапные апгрейды библиотеки туда не входят. И как это сочетается с жизненным циклом проекта? У тебя пасхальный релиз завтра, а какие-то клоуны из соседней команды ломают твой код своими апдейтами. Или апдейты приезжают не в мастер, а в ветку? Кто тогда отвечает за то чтобы эта ветка была смерджена в мастер?
С версиями как раз все просто, старая версия объявляется устаревшей, назначается план поддержки на какой-то срок, все пользователи включают миграцию в планы разработки и за несколько месяцев без суеты переезжают.
Здравствуйте, Miroff, Вы писали:
M>Если пользоваелям норм, то и не надо ничего менять. Сделали сервис, запустили в прод и он там крутится годами не останавливаясь. Зачем ему непременно обновлять библиотеки?
Так не бывает, всегда надо что-то обновлять. Хотя бы безопасность. Но чаще всего идут доработки и развитие в любом случае.
vsb>>А когда версия одна — если хочешь что-то сломать — будь добр, пофикси всех клиентов в том же коммите. Не хочешь фиксить — значит и ломать не очень хочется.
M>А тестировать эти фиксы кто будет? Владелец библиотеки? Так у него в чужом коде компетенции нет, он не знает что там и почему.
Тестироваться будет само. Автотесты, фич-флаги, сознательность и тд.
> Владелец кода? А ему это зачем, у него свои планы по разработке, M> внезапные апгрейды библиотеки туда не входят. И как это сочетается с жизненным циклом проекта? У тебя пасхальный релиз завтра, а какие-то клоуны из соседней команды ломают твой код своими апдейтами. Или апдейты приезжают не в мастер, а в ветку? Кто тогда отвечает за то чтобы эта ветка была смерджена в мастер?
Нет никаких пасхальных релизов. Ушёл коммит, собрался, прогнались тесты и всё ушло в прод.
M>С версиями как раз все просто, старая версия объявляется устаревшей, назначается план поддержки на какой-то срок, все пользователи включают миграцию в планы разработки и за несколько месяцев без суеты переезжают.
Или не переезжают, куда им торопиться, не горит же. Некоторые вон до сих пор на 6 жаве сидят.
M>Если пользоваелям норм, то и не надо ничего менять. Сделали сервис, запустили в прод и он там крутится годами не останавливаясь. Зачем ему непременно обновлять библиотеки?
Чтобы добавить новые фичи. Самому сервису эти фичи может и не нужны, но инфраструктура требует изменений — начиная от security, и заканчивая всякими там legal obligations, ну, скажем, PCI compliance.
Здравствуйте, vsb, Вы писали:
vsb>Это не минусы, с большими репозиториями работают не так, у гита есть специальные расширения для решения этой проблемы.
а что за расширения?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
vsb>>Это не минусы, с большими репозиториями работают не так, у гита есть специальные расширения для решения этой проблемы.
B>а что за расширения?
Здравствуйте, SkyDance, Вы писали:
M>>И в чем профит такого подхода? Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск. SD>Его никогда целиком не чекаутят. Используют всякие там on-demand файловые системы и симуляторых таковых.
Здравствуйте, SkyDance, Вы писали:
S>>Например? SD>У каждой компании свой колхоз. Почти всегда этот колхоз работает только на жестко контролируемой виртуалке, на которой, собственно, и ведется разработка. Компьютеры, которые дают сотрудникаам, очень часто есть просто монитор для терминала этого сервера. Вся разработка — удаленно.
1) Имел в виду пример вот этого -- "Распределенные кэширующие билд-системы"?
2)А у вас в фб также, т.е. термнал дают?
Здравствуйте, vsb, Вы писали:
vsb>В том, что нет возни с версиями, версия всегда ровно одна — последняя.
Это уже не просто про репы. Это, буквально, означает возможность только больших релизов всего сразу. С такими идеями во многих конторах тебя сразу пошлют, без разговоров.
M>>А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного. vsb>Ну у гугла, микрософта, фейсбука, твиттера, юбера, эйрбнб получается, это из того, что я знаю.
Это у гугла то с его любовью к микросервисам получается огромный реп?
Здравствуйте, Ночной Смотрящий, Вы писали:
vsb>>В том, что нет возни с версиями, версия всегда ровно одна — последняя.
НС>Это уже не просто про репы. Это, буквально, означает возможность только больших релизов всего сразу. С такими идеями во многих конторах тебя сразу пошлют, без разговоров.
Релизы делаются постоянно и непрерывно. Что закоммитил в главную ветку, то ушло на релиз. Конечно со всякими фич-флагами, канарейками и тд.
M>>>А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного. vsb>>Ну у гугла, микрософта, фейсбука, твиттера, юбера, эйрбнб получается, это из того, что я знаю.
НС>Это у гугла то с его любовью к микросервисам получается огромный реп?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> Ты не сможешь делать постоянно и непрерывно релизы продукта, в который вовлечено большое количество команд, целиком.
А что мешает?
НС> НС>>Это у гугла то с его любовью к микросервисам получается огромный реп? НС> vsb>Да. НС> Нет.
Здравствуйте, Anton Batenev, Вы писали:
НС>> Ты не сможешь делать постоянно и непрерывно релизы продукта, в который вовлечено большое количество команд, целиком. AB>А что мешает?
Необходимость синхронизации всех команд в плане готовности фич. Тот самый упомянутый тут МС начинал подготовку к релизу винды года за полтора, и почти никогда в эти полтора года не укладывался.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> НС>> Ты не сможешь делать постоянно и непрерывно релизы продукта, в который вовлечено большое количество команд, целиком. НС> AB>А что мешает? НС> Необходимость синхронизации всех команд в плане готовности фич. Тот самый упомянутый тут МС начинал подготовку к релизу винды года за полтора, и почти никогда в эти полтора года не укладывался.
Не, это про маркетинг. Технически в монорепозитории ничего не мешает собирать и выпускать продукт с отсутствующей фитчей хоть по 100 раз в день. Конкретный feature set сборки может определяться как в compile так и в runtime — с этим обычно ни у кого не возникает сложностей.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> AB>Не, это про маркетинг. НС> Не, это не про маркетинг, а про product management.
Да без разницы как это называть — к техническим аспектам сборки релиза/билда из кодовой базы в любой конфигурации репозиториев это не имеет никакого отношения.
Здравствуйте, Anton Batenev, Вы писали:
AB>Да без разницы как это называть — к техническим аспектам сборки релиза/билда из кодовой базы в любой конфигурации репозиториев это не имеет никакого отношения.
Крайне важно, чтобы у общего компонента был ответственный.
1) Это может быть команда. Например, в одной компании у нас все общие модули были поделены между командами: каждая команда отвечала за 1 или несколько общих компонентов. Соответственно, мержи/фиксы проверяются этой командой, либо же новые фичи/фиксы реквестятся у этой команды.
2) Можно назначить конкретного одного человека мейнтейнером 1 компонента. Обычно в компании есть люди, которые хотят больше ответственности/больше зп/апнуть левел/стать тим-лидом и прочее. Вот тут и можно совместить: дать человеку порулить и отвечать за небольшой кусок, а там и опыта наберется, и понятно будет, тянет или нет (например, на сеньора), а то и глади вокруг него сформируется команда и будет тим-лидить, и компонент поддерживаемый будет.
А как этот компонент будет встраиваться в другие — это зависит от множества факторов: у кого-то SVN; у кого-то монорепа; у кого-то микросервисы; где-то плюсовые компоненты; где-то все в докерах. Важно, в любом случае, иметь API, поддерживать его в рабочем состоянии, не ломать его, обновлять доку, ну и прочие подобные вещи. Как, собсно, и у внешнего продукта. Только в данном случае клиенты — твои коллеги.
Здравствуйте, Ночной Смотрящий, Вы писали: НС>Необходимость синхронизации всех команд в плане готовности фич. Тот самый упомянутый тут МС начинал подготовку к релизу винды года за полтора, и почти никогда в эти полтора года не укладывался.
Так это ж они как раз и рассказывали про дерево репозиториев, в котором от коммита в ядро новых фич шатдауна винды до возможности использовать их в меню кнопочки Start проходило три месяца.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Anton Batenev, Вы писали:
M>> Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск. AB>Его чекаутят или селективно (нужное подмножество директорий) или лениво (подгружая / кэшируя по мере необходимости).
И этим вся идея монорепы в принципе устраняется — каждый работает над своим субкомпонентом.
AB>Не очень понятно почему не можешь. Зависимость по исходникам (вместо зависимости по артефактам) — твой код собирается с текущей версией исходного кода другого проекта.
Что точно так же можно сделать и по нескольким репам. Всё равно из полного терабайта (чуть-чуть утрирую) исходников выбирается только подмножество.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Anton Batenev, Вы писали:
НС>>> Ты не сможешь делать постоянно и непрерывно релизы продукта, в который вовлечено большое количество команд, целиком. AB>>А что мешает?
НС>Необходимость синхронизации всех команд в плане готовности фич. Тот самый упомянутый тут МС начинал подготовку к релизу винды года за полтора, и почти никогда в эти полтора года не укладывался.
Это проблема исключительно МС и feature-based подхода.
С их маркетингом, да, нужно, чтобы выходил полностью новый продукт со 100500 новшествами, а не раз в неделю по 2-3 новым фичам. Но далеко не у всех такие проблемы.
Здравствуйте, SkyDance, Вы писали:
R>>В идеале: Однако, единственная работающая идеально схема — это когда каждая новая версия библиотеки обеспечивает вплоть до бинарной совместимости со всеми предыдущими версиями, пока они используются. Т.е. что-то типа libc/libstdc++, когда все символы версионированы и новая функциональность выпускается с символами под новыми версиями
SD>Без шансов, можно даже не пытаться. Слишком сложно научить среднего разработчика.
Что сложного в задаче добавить пару строк определённого формата в исходник и пару строк в linker script?
SD> И в тестировании тот еще ад.
Здравствуйте, Barbar1an, Вы писали:
B>как вообще это делается?
B>ну предположим компания очень крупная и у нее 100500 проектов, и которые ессно обязательно испольщзуют общие компоненты B>как такое версионится?
В яндексе — монорепка на всё-всё-всё. Система версионирования там какая-то своя, что-то вроде на базе SVN, как я понял. Система сборки — тоже своя
N>Что сложного в задаче добавить пару строк определённого формата в исходник и пару строк в linker script?
Речь не о linker script, а о том, что в современном мире код обычно очень распределенный. То есть библиотека часто попросту делает вызов к сетевому сервису, который уже что-то там делает. Почему так? Потому что это позволяет владельцу библиотеки сохранять полный контроль, и выкатывать изменения без каких-либо действий с твоей стороны.
Обеспечивать совместимость — очень трудно.
N>Чем? Есть тест на новую версию и тест на старую.
Это и называется ад, когда у тебя 100 старых версий, и надо поддерживать совместимость всего со всем. Я поддерживал некоторое количество open source библиотек, которые должны были работать с разными версиями компилятора, и разными версиями билд-тула. Геморрой был тот еще. Спасениям явилось включение этих библиотек в стандартную библиотеку языка (хотя и это прошло не без проблем, все еще мне аукается).
Мы уже победили, просто это еще не так заметно...
