Как правильно использовать ветвления или отдельные репозитории для поддержки нескольких версий кода, которые не имеют обратной совместимости?

Question

Я пишу надстройки для Revit. Эти надстройки зависят от библиотек Revit API. Эти библиотеки меняются с каждой новой версией Revit (2018, 2019, 2020 и др. c). К сожалению, они не имеют обратной совместимости, поэтому я не могу использовать свою надстройку с 2018 по 2020 год. Это означает, что я поддерживаю отдельные репозитории своего собственного кода на 2018, 2019 и 2020 годы. В настоящее время я использую запросы извлечения, так что если Я делаю изменения в 2018 году, я могу перенести их в 2019 и 2020 годы. Проблема в том, что, когда приходит запрос, он обновляет мои библиотеки 2019/2020 обратно, чтобы ссылаться на библиотеки 2018 года. Затем я должен go вернуться обратно и убедиться, что он ссылается на правильную библиотеку.

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

Answer 1

Вы уверены, что ваша надстройка 2018 не может быть использована в Revit 2020?

Во многих случаях, если не в большинстве случаев, верно обратное.

Как правило, вы можете использовать надстройку, скомпилированную для предыдущей версии Revit и в более поздних версиях.

Если вы обращаетесь к функциональности Revit API, которая изменилась между версиями, Вы можете справиться с этим, скомпилировав для более ранней версии Revit и добавив. NET функциональность времени выполнения, чтобы проверить во время выполнения, вызывать ли старую или новую версию Revit API. Вызовы, которые изменились, могут динамически обновляться для новой версии во время выполнения.

Посмотрите Строительный кодер Multi-Version Add-in для полного примера реализации.

Тем не менее, я все еще полностью согласен с вашим вопросом как таковым; во многих случаях вам потребуется отдельная чистая обновленная версия надстройки для каждой версии Revit, чтобы избежать сложности и улучшить читаемость кода. Для этого я полностью согласен с Ôrel в ведении отдельной ветки для каждой версии и объединении обновлений в другие ветки.

Answer 2

У меня та же проблема с надстройкой, которую я написал. Из-за изменения API я должен делать отдельные версии в зависимости от года, связанного с надстройкой. Я создал решение с отдельными проектами для каждой версии, общим кодом и библиотеками, чтобы уменьшить количество дублирующегося кода. К сожалению, я настроил это после создания второй версии, поэтому не весь код был правильно разделен. Однако это должно дать вам представление о том, как это можно настроить. Это можно увидеть в репозитории github: CreateSheets .

Обратите внимание, что, хотя это и уменьшает объем кода, он требует дополнительной работы, так как изменения в общем коде должны рассмотреть каждую версию.