CODEWITHSUNDEEP
gitbitbucketrevit-api
skeletank
skeletank

Reputation: 2888

What is the proper way to use branching or separate repositories to maintain multiple versions of code that are not backward compatible?

I write add-ins for Revit. These add-ins depend on the Revit API libraries. These libraries change with each new version of Revit (2018, 2019, 2020, etc). Unfortunately they are not backward compatible so I can't use my add-in from 2018 with 2020. This means that I maintain separate repositories of my own code for 2018, 2019, and 2020. I'm currently using pull requests so that if I make a change in 2018 I can move it across to 2019 and 2020. The problem is that when the request comes across it updates my 2019/2020 libraries back to reference the 2018 libraries. Then I have to go back in and make sure that it references the correct library.

How should I be doing this to avoid this issue every time that I need to push a change to other versions?

Upvotes: 1

Views: 191

Answers (2)

Jeff
Jeff

Reputation: 654

I have the same issue with an Add-in I wrote. Due to an API change, I have to make separate versions depending on the year associated with the Addin. I set-up a solution with separate projects for each version and shared code and libraries to reduce the amount of duplicate code. Unfortunately, I set this up after creating the second version, so not all of the code has been properly sub-divided. However, this should give you an idea of how this could be set-up. You can see this in the github repository: CreateSheets.

Note that, although this does reduce the the amount of code, it takes a bit of extra work as changes to shared code needs to consider every version.

Upvotes: 0

Jeremy Tammik
Jeremy Tammik

Reputation: 8339

Are you sure that your 2018 add-in cannot be used in Revit 2020?

In many cases, if not most, the opposite is true.

In general, you can use an add-in compiled for a previous version of Revit in later versions as well.

If you are making calls to Revit API functionality that changed between the versions, you can handle that by compiling for the earlier version of Revit and adding .NET runtime functionality to check at runtime whether to call the old or new version of the Revit API. The calls that changed can be updated dynamically for the new version at runtime.

Look at The Building Coder Multi-Version Add-in for a full implementation sample.

That said, I still totally agree with your question per se; in many cases, you will want a separate clean updated version of your add-in for each version of Revit, to avoid complexity and enhance code readability. For that, I totally agree with Ôrel on maintaining a separate branch for each version and merging updates into other branches.

Upvotes: 1

Related Questions