Branching webservice api version - wcf

Question

I'm working with my team on the "core" domain of our job, we have several DBs, Webservices, importer, etc... We expose the domain services to other teams through a backend WCF webservice. This webservice is cut in several api (or areas).
We deploy this on several production server (~ 80) (1 server <-> 1 customer).
Problem is: Some api goes public and we must maintain the same contract throught many releases. Others team want more flexibility (3 internal api contract version) as they can't follow our delivery rate (longer cycle)
Actually we are only serving this as a whole, and we are using a classic three branch branching (DEV/MAIN/RELEASE'n')
I'm trying to upgrade my TFS Team collection organization to handle a defined version range of each API version:
API Foo v2 (hxxp://-host-/api/foo/v2/...)
API Foo v3 (hxxp://-host-/api/foo/v3/...)
API Bar v1 (hxxp://-host-/api/bar/v1/...)
API Bar v2 (hxxp://-host-/api/bar/v2/...)
Currently we have the following branching schema:
$\MyTeamCollection
|___\DEV {Branch}
|___\Databases
|___\MyDBProj (SSDT)
|___\Documents
|___\MyWebService\MyWebSvc.Usage.docx
|___\Projects
|___\MyWebService.Core
|___\MyWebService.API.Bar
|___\MyWebService.API.Foo
|___\Shared
|___\MyDB\MyDB.DacPac, etc...
|___\MyWebService\MyWebsvc.Bar.Contract.Dll <-- WCF DataContract/ServiceContract
|___\MyWebService\MyWebsvc.Foo.Contract.Dll
|___\MAIN {Branch} <-- This one is what is on the integration server
|___\R1 {Branch} <-- This one went on a production server and is kept aside
|___\R2 {Branch}
|___\Archive
|___\R0 {Branch} <-- This one is obsolete but is archived here
Actually it handles a group of single api versioning. => Each release ship with a set of latest api version (Foo, Bar)
My question is how can I evolve this to handle multiple Api Version in each release (Foo-v1, Foo-v2, bar-v3, bar-v4)
Should i create branch inside branch? Won't this be a nightmare?
Any actual working teamcollection organization on your side?
Thanks,
-Jeremy.
Some additions:
All my clients are .Net, we provide them the assembly named MyWebsvc.Foo.Contract.Dll. This assembly contains:
ServiceContract interface which is implemented by a proxy pattern
[ServiceContract]
public interface IFooService {
Foo Get(int Id);
}
And all data contract needed (DTO + Serialization)
[DataContract]
public class Foo {
// ...
}
On the web service side there is the actual implementation
public class FooServiceImpl : FooApi.IFooService { ... }

Answer 1

For the purpose of this answer, I imagine that you have thoroughly reviewed the abundance of version control branching and merging guidance available online. As such, I suspect that the answer may not be found in “more” version control, but rather in a modest shift in the way features are enabled and available for customer use. Therefore, you may find that implementing a feature toggle solution will reduce the number of release versions that you need to maintain. The following article by Martin Fowler provides a good overview of feature toggles.
http://martinfowler.com/bliki/FeatureToggle.html
Our development team has utilized the concept of feature toggles, in our self-hosted WCF Windows Services, to provide a fully configurable set of endpoints that can be enabled/disabled (and adjusted) via configuration. In such scenarios, we typically utilize the customers’ data repository (database, ldap, etc) to store the configuration values and toggle switches, then when the service runs, it searches the repository for the configuration and then sets up and enables the interfaces in the manner the customer needs/wants.
Hope this helps.
Regards.

Answer 2

Jeremy,
there are a few questions you need to consider.
a) are your clients .Net as well or can they be in any technology? WCF has a really nice "compatible" versioning mechanism, but unfortunately it's non standard and only works with .Net clients
b) do you have the ability to give some guidance as to how the clients consume the services?
The only way to keep this problem under control is to adopt a "compatible" versioning strategy. As you pointed out, you want to have several (max 3) major releases in production and each time you evolve one or more major release you want to create a compatible (minor) version such that there is always one and only one release for each major version of the service running.
From a TFS perspective, I would consider each major version independent from each other, as in essence, they are somewhat independent services. I understand that creates a bit more work since you could have some update that applies to more than one major release, but IMHO, it's not worth the trouble to try to optimize that, unless you are actively working on all major versions simultaneously.
Achieving "compatibility" from one version to the next is not that hard, there are number of guidelines you want to follow both on the service side and the client side. I co-authored this article way back in 2008. http://www.infoq.com/articles/contract-versioning-comp2
I also wrote that blog post recently specifically for HTTP based APIs: http://www.ebpml.org/blog2/index.php/2013/04/13/formalizing-the-api-style
I want to emphasize that it's generally a good idea to use a minor version that is provided by the client to indicate which version of the service was in effect when it was built. The reason for that is that you can handle small breaking changes in a compatible way by knowing which minor version of the service it is compatible with. You still have a single release per major version and the variants are directly handled by the latest (minor) version of the service.
Versioning is key to a healthy API that allows clients to upgrade on their own terms (risk, budget, resources,...) and to the best of my knowledge, a "compatible versioning" strategy is the one that works best.