Advice: Developing two projects where one is an extension of the other

Question

The Two Projects

I work at a pretty small software company, and I'm currently in a situation where I'm at the end of development for "Project A", about to start development for "Project B". Project B is supposed to be an "extension" of Project A (both are primarily web apps).

In Project B, the plan is to not only add brand new features, but modify some of the existing things from Project A; for example, some of the web pages. The difficulty is that we still want to be able to distribute Project A, without any of the features from Project B, but with any "A"-related bug fixes that we end up doing while we work on "B".

Method 1: Branching

The way I'm thinking about it is that Project A is like the "stable" branch and Project B is like the "dev" branch, but "dev" never gets merged back into "stable". We have concerns with this approach because it seems like it will require a lot of discipline to make sure that bug-fix changes are always committed to the Project A branch and then merged up to the Project B branch (as opposed to fixes being implemented on the Project B branch and needing to manually copy them back into the Project A branch).

Method 2: Plugin Architecture

Alternatively, we could start turning things into sort of "plugins" wherever there needs to be a "difference" between Project A and B. This way also seems like it could turn into a tangled mess, since we don't yet know exactly what changes will be needed.

The Choice

Right now, I see it as a choice between the lesser of two evils (read 'difficulties'). Based on your experience, do you have any advice that will help with my choice? Are there any other ways to manage the split between the two projects that I might have overlooked?

Answer 1

Regardless of the used SCM, Branch-based method is faster in implementing, simpler in management and just better, especially if you'll follow "Branch per task" workflow

• "Project A" is long-term branch
• "Project B" is long-term branch also, created at some moment from "Project A"
• Each task (feature or bugfix or ...) is separate short-term branch, which, after finishing, can be (have to be) merged into one or more targets

Answer 2

A branching strategy for versions would probably be best in a scenario like this. Sure, it requires discipline, but so do most aspects of software development.

Here is an example strategy to give you some ideas (despite the name...it is not really SCM specific, but does contain some helpful info for DVCS).

A plugin architecture would really only apply if plugins are part of the functionality of the application (something like the architecture of Drupal). They do have their place, but their place is not project versioning.

Answer 3

For your scenario Method 2 i.e Plugin based seems better solution. Its going to be pain to make code modular and extensible for first time but one you have successfully done it, and further development will be easier.

If you plan to go for Method 2, first of all you need to clearly state out purpose for both the apps and figure out common ground and how can entire thing be bifurcated into different modules. Be really clear on defining boundaries for you modules based on their purpose as if done properly can speed your development.