Structuring the source code for multiple versions of web services

Question

Is there a convention for structuring the source code when there are multiple versions of the same web service in the same source code trunk or branch?

Here's our situation.

We version our web services by including the version number in the wsdl URL like this:

url/project/1.0/WebServiceA?wsdl

I'm going to deploy version 1.1 of WebServiceA along with version 1.0 so users of 1.0 don't have to change anything. Version 1.0 and 1.1 of WebServiceA will have their own seperate Java classes.

I want to deploy both versions in the same .war file. (We could adopt a policy of only one version of a web service in the .war and deploy other versions in their own .war. This would result in an increased number of.wars to deploy when we get several versions of several web services. I would prefer to deploy only one .war.)

I'm thinking we should just use a seperate package structure for the various versions:

com.company.dept.ws.WebServiceA  (version 1.0)
com.company.dept.ws.v11.WebServiceA  (version 1.1)

com.company.dept.ws.WebServiceB  (version 1.0)
com.company.dept.ws.v11.WebServiceB  (version 1.1)
com.company.dept.ws.v12.WebServiceB  (version 1.2)

The Java classes under ws., ws.v11., and ws.v12. would be seperate Java classes.

Can you see any problems down the road with this convention?

If there is a tried-and-true convention for structuring the source code for multiple versions of web service code I'd like to hear about it before I make up my own.

Thanks.

Dean

Answer 1

Since you say you want these versions to all be "in the same source code trunk or branch" I think part of the answer depends on the source control system you're using, and whether or not you ever plan on fixing bugs in older versions.

If you ever want to fix bugs in older versions you'll want the ability to integrate changes forward or backwards between the different versions. For example, suppose you discover a critical security problem that exists in versions 1.0, 1.1 and 1.2. You aren't going to want to fix it 3 times. Most source control systems will let you do that sort of integration between related branches. Some (like Perforce, and I believe also git, and probably a few others) will let you integrate changes between files even within a branch. (in fact, Perforce's concept of a "branch" is just a convenience for recording inter-file integrates)

So you need to think about whether you'll need to make these sorts of multi-version fixes, and if so, can your sorce control system handle intra-branch integrations. If not, then you might be better off using a separate branch for each version.