LINUX.ORG.RU

как поддерживать множество версий софта?

 


0

1

Допустим, есть у вас некий софт, который вы продаете.

Почти каждый покупатель просит добавить в него свои фичи, которые зачастую требуют изменения основных функций в софте, даже его главного алгоритма.

До какого-то времени всё решают настройки - каждую «фичу» можно отключить. Но вот опций становится всё больше и больше - софт становится монстром и при этом его функционал имеет свойство со временем ломаться, а весь тестировать каждый день нереально.

Вам приходит идея продавать некую базовую версию, в которой есть только то, что надо всем клиентам, а когда просят доработки - делать под каждого клиента форк.

Важно - то что рано или поздно клиент пропадет и форк можно будет выкидывать, хранить и поддерживать их можно только для того кто их заказал.

И вот ломается одна из основных функций - вы фиксите её в базовом комплекте, но надо фиксить руками также и во всех форках.
И автозаменой текста тут не обойтись, так как форки могут быть очень уникальными и просто сломаются после апдейта.
Опять же нет смысла фиксить те форки, заказчики которых давно не обращаются к вам за апдейтами.

Можно обновлять форк тогда, когда заказчик обратится за апдейтом, но:
1. бесплатными апдейтами тут уже не порадуешь, как бы ни хотелось, потому что даже тупой перенос кода требует сил и времени.

2. если за последнее время было много апдейтов, как проследить их все и правильно перенести? Простым diff-ом не обойтись, т.к. форк может быть уникальным и сильно отличаться.
Остается разве что записывать каждый фикс в отдельный changelog, где подробно излагать его суть

Подозреваю что есть ещё подводные камни, но я и к этим двум не могу придумать красивого решения уже давно

★★★

Последнее исправление: sergey-novikov (всего исправлений: 2)

А может быть будет удобнее весь проект разделить на модули по ярко выраженной функциональности и заниматься разработкой/поддержкой именно модулей, а не отдельных форков?

kravich ★★★★
()
Ответ на: комментарий от chg

А может быть будет удобнее весь проект разделить на модули по ярко выраженной функциональности и заниматься разработкой/поддержкой именно модулей, а не отдельных форков?

дело в том, что проект и так разделен на подпроекты, каждый из которых содержит уже по 10-20 модулей с разным функционалом.

Только вот заказчикам порой не подходит ни один модуль, а нужен новый - «такой же как тот, только с перламутровыми пуговицами» - и так появляется 21-ый модуль.

Конечно, можно просто не продавать новым покупателям эти индивидуальные модули, но дело в том, что код всех модулей растет из общей либы. Когда модулей 20, размер либы около 6к строк. И, как я вроде уже писал, многие модули нужны лишь тем кто их заказал, после чего заказчики со временем пропадают, а код их модулей остается в либе. Глобальные изменения для них же (которые вообще влияют на все модули сразу) - тоже остаются в либе.
Вот поэтому и хочется иметь на каждого заказчика свою либу, чтобы потом её можно было легко выбросить, а базовая либа оставалась чистой и безглючной.


embedded scripting вместо 100500 опций

уточню что софт на python3, там и так все является скриптом с инклудами.

Код нельзя хранить в виде универсальных кусков и складывать как кирпичи, потому что порой уникальный кусок сильно зависит от контекста и для его работы требуется менять основной алгоритм

sergey-novikov ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.