My department is planning on working on our next several releases (spanning a year) simultaneously. The powers that be are advocating we support this by refactoring all affected code into classes like AbstractGizmo, R1Gizmo, R2Gizmo, etc and use configuration (via Spring and/or ANT) to control which classes are used in a particular release. Ostensibly this is to save us the work of merging changes into multiple branches, especially when the changes are in the common code. However, I see this as a clear cases for branching and merging in version control (TFS, in our case).
However, I have very little experience on projects that have active streams of development like this. I'm sure others have (like Microsoft, with Windows XP, Vista, and 7). What's the best way to handle multiple simultaneous "streams" of development in version control? Do you branch and merge changes in version control, try to develop everything in one branch and use configuration or build scripts to assemble the different version, or something else?
P.S. We use TFS right now, but our version control strategy may not be constrained by it. A coworker of mine is pushing to switch to Git or Mercurial, and it seems like he's getting a bit of traction.