Недавно я столкнулся с довольно раздражающей (подтвержденной) ошибкой в программном пакете с открытым исходным кодом, который я интегрировал в свое приложение. Согласно общедоступному трекеру, эта ошибка была исправлена в последней версии программного обеспечения.
Иногда вам НУЖНО это исправление ошибки, чтобы избежать дорогостоящего рефакторинга конкретного модуля, однако по техническим и / или политическим причинам вы не сможете выполнить обновление до последней версии.
При проверке внесенных изменений в коде исправление кажется достаточно простым, и я считаю, что приемлемым вариантом было бы исправить сам код и перекомпилировать мою текущую утвержденную версию программного обеспечения, однако недоброжелатели хотят утверждать, что это почти всегда плохая идея. в том, что это рискованно и создает неприятную сложность.
По их мнению, поскольку это изменение кода было сделано нами исключительно для нашего использования, оно должно быть частью нашей кодовой базы, а это означает, что вместо того, чтобы представлять программное обеспечение с открытым исходным кодом в качестве сторонней зависимости, мы должны представить его как новый проект и включить его автоматизированное встраивание в наш процесс сборки.
Мне кажется, что это неправильно, так как мы будем вытаскивать их код из их репозитория управления исходным кодом в наш, и мы теряем историю всех изменений кода, которые были до этого. Также кажется, что это слишком сложно для такого маленького изменения кода, которое нужно сделать.
Было бы плохой идеей сделать вышеупомянутое в этом случае? Если так, то какова идеальная ситуация, когда открытый исходный код должен измениться, но только для вашей единственной выгоды в доме?
источник
Ответы:
Если вы не можете использовать более позднюю версию, в которой нет проблем, с которыми вы сталкиваетесь, вы можете выбрать один из следующих вариантов:
Я был на вашей позиции, вариант 2 (сделать кастомную вилку) часто является наиболее приемлемым из доступных решений. Это жизнь, когда имеешь дело с библиотеками с открытым исходным кодом, особенно с быстро развивающимися и имеющими дурную привычку нарушать обратную совместимость между выпусками (что, по моему опыту, является наиболее распространенной причиной для подобных вещей).
Для более чем нескольких библиотек OSS я и команды, в которых я участвовал, поручали обертки вокруг всех без исключения и доступ к функциям сторонних библиотек исключительно через эти обертки. Таким образом, если нам нужно заменить стороннюю библиотеку на версию, которая настолько отличается, что это нарушит наш код, изменения, по крайней мере, в значительной степени ограничиваются этой оболочкой. Это не самый хороший (добавляет код, может добавить сложность и стоимость производительности), но иногда это единственный способ сохранить ваше здравомыслие.
источник
То, что вы собираетесь сделать, является плохой идеей в более распространенном случае, когда вы комплектуете стороннее программное обеспечение и намереваетесь отслеживать их выпуски . Обычно люди делают это, потому что им нужна особенность в стороннем компоненте, которую разработчики не хотят реализовывать или реализовывать так, как вам нужно.
Вы, однако, явно говорит , что вы не модернизировать комплектный код. Это делает вас сторонником стороннего компонента. Поэтому, будет ли это исправление хорошей идеей или нет, зависит только от того, насколько хорошо вы понимаете этот код, чтобы быть уверенным в желаемом эффекте. Твоих интеграционных тестов должно быть достаточно, чтобы убедиться, что он действительно делает то, что ты предполагаешь. Поэтому, когда вы рассказываете ситуацию, мне кажется, что ваши рецензенты ошибаются.
источник
В этом нет ничего плохого, если каждый может понести издержки, выгоды и риски.
Когда у вас есть работа, perfect (наличие сторонней библиотеки - именно то, что вам нужно) - это враг достаточно хорошего (исправляя ее самостоятельно), и иногда вам приходится делать такие вещи. Я выполнил ряд проектов, в которых мы купили исходные лицензии для коммерческих библиотек, чтобы мы могли решить проблемы до того, как вендор доберется до них.
Это плохая идея, если у вас нет возможностей справиться с анализом чужого кода, выявлением проблемы и написанием исправления. Это верно, является ли код внутренним или третьим лицом; единственная разница в том, была ли она брошена на кабину или стену здания до того, как приземлилась на колени.
Если ваши хулители просто отбрасывают идею, не взвесив затраты на не делать этот патч, они не делают свою домашнюю работу. Если у вас есть много внутреннего кода, на который повлияла ошибка, которую исправит ваш патч, вам придется пройти и изменить его, чтобы обойти его, и перепроверить все, чтобы убедиться, что он работает правильно. Затем, если вы когда-нибудь обновите пакет до версии с исправленными ошибками, вам, возможно, придется найти и удалить свои обходные пути и заново протестировать. Это также сопряжено с риском, например, пропущение измененного вами случая или недостаточное тестирование. Лично, если бы у меня была возможность исправить ошибку в ее источнике, я бы предпочел сделать это там, а не гоняться за остальной частью кода мухобойкой и надеяться, что я все получу.
Если вы делаете патч, патч является частью вашего собственного кода, что означает, что вы должны сделать его частью своего процесса. Это ничем не отличается от добавления чего-то, что на 100% соответствует вашему коду в вашей системе. Рассматривайте сторонний дистрибутив как священный и помещайте его в модуль, как если бы это был исходный код. Любые патчи, которые вы пишете, хранятся вместе с ним в отдельных файлах и применяются как часть процесса сборки. Таким образом, вы всегда переходите от чистого источника к исправленному исходному к встроенному продукту и можете точно показать, что происходит. (Некоторые люди распаковывают, вручную исправляют, перепаковывают и сохраняют это в системе контроля версий. Это плохо.)
Если вы рассматриваете стороннюю библиотеку как стороннюю зависимость, у вас нет этой истории для начала, и вы ничего не теряете. Если у вас есть постоянный доступ к репозиторию третьей стороны, вы можете обратиться к нему, если вам нужно. Сторонние выпуски должны рассматриваться как аморфные капли, которые вы вносите в свою систему без изменений. Если вам нужно посмотреть на изменения между выпуском, который вы используете, и более поздними выпусками, вы можете это сделать, и, если хотите, придумать исправления для старой версии, которые включают изменения, которые вы хотите.
Если ваш процесс сборки достаточно сложен, добавить это не должно быть сложнее, чем добавление собственного кода. Есть небольшой труд, чтобы довести его до того момента, когда процесс распаковки / исправления / сборки будет автоматическим, но как только он будет завершен, он будет завершен навсегда. Сейчас может быть одна ошибка, но в будущем их может быть двадцать. Если да, то вы будете намного счастливее, если заложите основу для поддержки всего этого сейчас, потому что это сделает работу со следующими 19 гораздо менее трудоемкой.
источник
То, что вы хотите сделать, кажется достаточно разумным, но, похоже, существуют (здравые?) Причины для противодействия этому. Я не буду сравнивать предложенные решения, но, возможно, есть способ, которым вы могли бы съесть свой торт и съесть его тоже:
Если рассматриваемый проект с открытым исходным кодом позволяет это сделать, внесите исправленные ошибки в их репозиторий. То есть, если вы используете версию 1.5.2, а текущая стабильная версия - 1.6.1, добавьте патч для 1.5.2. Если он будет принят, вы можете получить фиксированный источник прямо из репозитория (возможно, как версия 1.5.3) и сделать всех счастливыми.
Другими словами: исправьте это для всех, кто в вашей ситуации тоже. Конечно, это возможно только в том случае, если проект поддерживает (или, по крайней мере, разрешает) обновления выпущенных версий. Но это, безусловно, довольно стандартная практика в наши дни.
источник