Re: Versioning Techniques
We combine namespace and the version id. We do a namespace change for non-backwards compatible changes and a version id attribute change if the change is backwards compatible. And we use the date pattern in the namespace to distinguish the versions. - Yagiz -
Re: Versioning Techniques
How about your source packages? I have found that I need to manage the endpoint classes as well. I suppose all additional properties could be omitted from the wsdl, but at some point a complete refactor may be in order. In this case, I will need to branch the source too. Package names cannot contain numbers, so it gets really ugly. On 11/23/05, Yagiz Erkan [EMAIL PROTECTED] wrote: We combine namespace and the version id. We do a namespace change fornon-backwards compatible changes and a version id attribute change ifthe change is backwards compatible. And we use the date pattern in thenamespace to distinguish the versions. - Yagiz -
Versioning Techniques
What is the best way(s) to version SOAP applications. Since these are externally facing APIs, they must provide a reliable means for third parties to consume services. I must ensure that the wsdl that I provide will not change. However, change is inevitable. Therefore, there must be a way to version SOAP applications. I can imagine that this has mostly something to do with the wsdl url. If so, what would a typical project structure look like? Are there any other ways that you've overcome this problem?
