I'm working on a project (A development accelerator) which had dependencies with a 3rd party NuGet package for a CMS application. The external NuGet package has some breaking code changes to our application from v1.1 to v1.2.
Since our client could choose to user either v1.1 or v1.2 of the CMS application, so we need to support code base for both. The development accelerator continues to be developed against with additional features added on a regular basis. The problem is that there are a few very minor code changes we need to main for v1.1 and v1.2 of the external dependencies on our main code base. We would need to continue to develop against both v1.1 and v1.2 of our accelerator.
What would you recommend we do? Do we maintain multiple release branches and just do our development against each? Is there easy way to code against a develop branch and only merge the changes to release branch that won't break either?
1 Answer 1
I think this is less a source control problem and more a build configuration problem.
You still have one codebase that you develop against, you just have different ways you might want to output it. Break up the "different" code into separate files and use a build configuration to determine which version gets built.
Then, your source control is all "normal" and not subject to screwy branch/merge strategies, which can turn into a big mess pretty quickly.
-
How would I go about this in Visual Studio? I don't think there is a way to install multiple versions of the same NuGet package or have different packages.config for a single project.Chirag Patel– Chirag Patel03/09/2017 21:02:10Commented Mar 9, 2017 at 21:02