Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

3 Answers

up vote 5 down vote accepted

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
share|improve this answer
add comment

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.

share|improve this answer
    
BTW - NVIE-model is real nightmare in real-life with big project –  Lazy Badger Jan 4 '13 at 19:34
1  
@LazyBadger Interesting. Care to explain? –  smp7d Jan 4 '13 at 20:11
    
Easy... Set of dependent-features (even in pure linear case) –  Lazy Badger Jan 4 '13 at 20:49
    
@LazyBadger Ah, I would suggest that the model not be taken to that level of literal detail. A feature set dev branch usually soon follows. –  smp7d Jan 7 '13 at 14:57
add comment

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.

share|improve this answer
    
+1 for outlining a modular approach. You may want to mention a layered design (e.g. MVC, probably using a framework such as ember.js) –  miraculixx Jan 4 '13 at 19:37
    
If it helps, "Project A" was build with Lift (scala web framework) –  Dylan Halperin Jan 4 '13 at 20:22
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.