I work for a company that does plugin development. We typically maintain our plugins for the 2 most recent major versions of the parent application. Major releases of the parent application's plugin API are usually mostly backwards compatible, but there are always some obsoleted/deprecated pieces along with several new APIs. As such, we usually have 2 lines of development that diverge over time. At first the divergences are small as we start by fixing all the obsolete calls. Over time the divergences can become large as we start to use the new APIs. Merging between these branches can be a pain as you have to make sure you aren't merging code that uses parts of the API that aren't available in the other version.
I need some help in determining the best workflow for this situation. I will lay out some of my ideas below. The parent application releases new major versions on a yearly basis. As such, let's assume a plugin API for 2013 and 2014.
1. Maintaining a branch for each version of the API
We have 2 long-running centralized branches, 1 for each version of the API (e.g. develop_2013, develop_2014). We develop against develop_2013 and consistently merge to develop_2014. Being that the API is mostly backwards compatible, this usually works fine. Any development against new pieces of the API is done in develop_2014 and is not merged back.
I'm cautious of this method being that git is not really geared towards maintaining long-running divergent branches.
2. Fork for each version of the API
We now have a situation where we have a repository for each major version of the parent application (e.g. plugin_2013 and plugin_2014). We now must merge code between each repository through merge requests or by adding one as a remote to the other. We could perhaps cherry pick changes.
I'm cautious of this method because it introduces more overhead into the process.
If possible I would prefer to keep all development for a particular plugin contained within 1 repository. I am just concerned about the hassle of having 2 branches that will get more and more divergent over time.
So my original posting of this I've realized was due to my lack of experience with git. Maintaining 2 long-running branches in the same repo works fine for us. The real underlying concern that I didn't quite understand at the time I posted the question was that I didn't want to have to resolve the same merge conflicts every time I merged. I wasn't sure if git handled it out of the box, but rerere certainly would do the trick.