I'm starting to look at upgrading a couple of package I'm maintaining to version 8, but want to find a way to do it so I can most easily service issues and add features to the version 7 release as well.

I don't think I've seen a discussion on this here, but imagine a number of people are going through the same process, so thought would start one (please point me elsewhere if it has been discussed already).

Given my package is currently targeting Umbraco 7, and is version 1.0, I'm expecting to release a second one, targeting Umbraco 8, as version 2.0. And I'd like to, as easily as possible, be able to release 1.1 and 2.1 if I come up with a new feature that will be useful on both platforms.

There are a few approaches I'm considering:

1) is just to lean on source control. Perhaps have two branches - master-v7 and master-v8. master-v7 will be just renamed from current master and be version 1.0, and master-v8 will diverge from it, doing all the necessary to upgrade to Umbraco 8 and bumping the package to 2.0.

If in future I want to add a feature to the Umbraco 7/1.0 version, I can checkout that branch, and either directly apply code or cherry-pick and amend what I've added to the Umbraco 8/2.0 version.

So seems like that'll work, but might be a bit confusing to manage, will have some merges to handle.

2) is to take what's currently a single Visual Studio project/dll, and split it into three:

• One common project that has no Umbraco dependency
• One project, referencing the common one, targeting Umbraco 7 - from which the 1.0 package is built
• One project, referencing the common one, targeting Umbraco 8 - from which the 2.0 package is built

And then take on a task to migrate everything that doesn't depend on Umbraco into the common project.

In order to migrate as much as possible into the common project, I would likely drop usage of Umbraco helpers like extension methods, cache wrappers and configuration helpers, and implement (or copy!) them myself. Just so there's no need to reference an Umbraco version in the common project.

With this I'd just have one branch to maintain, and two projects to build and generate packages from for the two platforms.

Again, seems like this'll work, but of course this is an Umbraco package, and quite a bit of code will depend on it and not be easily migratable to a common project. So seems I'm going to end up with quite a bit of code duplication between the two package projects. And am concerned I'm still going to run into issues around versions of Umbraco's dependencies - e.g. NewtonSoft.Json, ClientDependency, that will need to be referenced in the common project and may also have changed in terms of referenced version between v7 and v8.

As an extra complication, seems that with either setup, if I ever wanted to introduce a breaking change to the Umbraco 7 version, I'd have nowhere to go with in terms of semantic versioning with a major version change (as 2.0 is taken for the Umbraco 8 version).

Given that, perhaps 3) - simply starting over with a new copy of the repo and maintaining both is the cleanest... but sounds like a lot of duplicated work.

For completeness, I guess option 4) is to go all-in on V8 for new feature development, and limit any changes to the v7 version to emergency bug fixes that would be handled via going back in source control - I guess similar to how Umbraco currently release security patches.

Downside here is obviously accepting that users of the package on Umbraco V7 won't get new features unless they also upgrade to V8.

So - other package developers, how are you considering tackling this please? A version of one or other that I've described? Or is there something better I'm missing? Thanks in advance for any suggestions/comments.