One important question here is what kind of changes are you looking to support?

Additional inputs to a given method?

Breaking changes (i.e. - removing attributes or changing data types)?

The approach to versioning may vary based on what changes you want/have to support.

Thanks for your response.

I want to stay flexible. So let’s say I want to support both breaking and non-breaking changes.

I’d love to hear some approaches.

When you're talking about versioning web services, there really is no single industry standard for doing so.

Some organizations use URL versioning, some use accept headers (for REST services, obviously), and some use parameter versioning.

For your use case, I think the best approach would be to use URL versioning, and rather than cloning the entire module, simply add a new SOAP endpoint with the version included in the endpoint name. So your first version would be:

SoapService_v1

and if you needed breaking changes, you would add a 

SoapService_v2 

with the necessary changes.

Non-breaking changes (i.e. - adding optional parameters) can be performed on the original (or most current) service version, while breaking changes (incompatible data type changes, removing parameters, adding mandatory parameters) would require creating a new endpoint.

A couple of things to keep in mind:

• In many cases, you can keep the majority of the logic that underlies your web service methods in reusable actions, so you can (and should) minimize duplication of the logic when adding new endpoints.
• If your consumers are all OutSystems applications, you may want to consider using Service Actions in OutSystems 11, as these may serve your needs better than SOAP services for such consumers.

G. Andrew Duthie Thank you for your response

How would that work if you're using structures as input and output variables and you're adding or changing attributes of those structures. They would change for both versions wouldn't they?