IBM's developerworks published an article on versioning of WSDL and UDDI at http://www-106.ibm.com/developerworks/webservices/library/ws-version/. It is a nicely written but somewhat incorrect assessment of compatibility.
I like the discussions about bindings and about operations and I found the discussion about versioning in UDDI to be illuminating. But there's a *lot* of versioning that can happen within the same set of operations and bindings, where the content of a message are changed in compatible manners.
First off, the authors make a common mistake of making the compatibility definition at the interface level. This is inappropriate because a WSDL operation means that both paries send and receive messages. The compatibility definition must be for one side or the other with respect to the contract for a message, and both sides need to be independently evaluated.
For example, the assertion that "addition of new operations is backwards compatible" is not always true. If a WSDL definition adds a new "output" operation, and the "client" doesn't know about it, it will fail when it sees the output operation.
In another example, the assertion that changing the structure of a complexType is always an incompatible change is not quite correct. There are abundant cases of where a parameter provides an extensibility point, and then an optional element is added. If the contract is correctly designed, particularly that unknown extensions are ignored, then certain interface changes be changed and both sides will still work.
The article also mostly avoids the discussion that there are 2 types of compatibility: forwards and backwards. Backwards compatibility is where newer software can understand older messages, ie interface and receiver updated and still works with older senders. Forwards compatibility is where older software works with newer messages, ie the interface and sender are updated and still works with older receivers. Forwards compatibility is mentioned in the article, but the distinction between backwards and forwards compatibility, and the relationship between extensions and optional content. Notice that the backwards and forwards compatibility are not at the interface level, they are at the message level.
The fundamental point of this is that the only way for either compatibility to work is when unknown (ie things in the future) things can be ignored, that is they are optional. Software should be built to handle change without having to be updated on both sides for every change. The advice, as roughly expressed, to change namespaces and deploy new software including a "mapping proxy" to handle change simply does not scale to the internet level. This brings the fragility problem of distributed objects to Web services, as I've outlined in Web services = or != distributed objects.
The point about data type changes, ie float to int, is well taken.
On the subject of version identification in UDDI, I think that the right way to go is for a WSDL namespace to identify compatible versions of web service, with a version attribute on the definitions file to indicate "minor", yet compatible, versions. This is the advice that I helped write in the W3C Web Architecture document section on XML formats and the TAG finding on extensibility and versioning. There is a proposal in the WSDL 2.0 WG to more formally talk about versioning of web services, including adding a "minor" version attribute and using the namespace name to identify compatible descriptions, and I'm hopeful this will come to pass.
In summary, I think the article should look a little more closely at what can be done to achieve compatible changes, and what recommendations should be made to users of technology to enable compatibility. As it is, it misses the mark on one of the very common cases, which is extension to complex types.