Depreciation of the SOAP interface in ADO/TFS

[rjmurillo]

Beginning in Jan 2020 and with TFS 2020 on-prem, the SOAP interface will no longer be supported.
https://docs.microsoft.com/en-us/azure/devops/integrate/concepts/wit-client-om-deprecation?view=azure-devops

Right now we support the reading capabilities through the REST interfaces, but do not generate patches to send back to the server. We also have quite a few SOAP-isms in the code to make the REST and SOAP clients behave in similar ways so we really just can swap one implementation for another.

It's a year out, but I'd like to get the discussion going about what we would like to do about this change. Some ideas:

• Drop support in the next major for SOAP (e.g. delete) and go REST all the way. We would need to give people a heads up by marking the SOAP classes as deprecated.
• Stop support for SOAP in the major, but kep the code. Code marked as deprecated with instructions to move to REST, but we won't do any enhancements to the SOAP implementations and minimal bug fixes. This allows people to use the latest version against older TFS instances.
• Some version of the first two where we phase it out over time. We don't have any telemetry so we can't measure the impact. All we have is the scream test (either by the community saying something or NuGet downloads dropping)

@MattKotsenas @pelavall Other ideas?

[MattKotsenas]

I think that given that we have finite support capacity, and that the SOAP clients are deprecated both for Azure DevOps and DevOps Server (formerly TFS), it doesn't make sense to continue to drag SOAP support along. We also run the risk of breaking people on older versions of TFS as we roll forward unless we start writing integration tests per server version (which I very much don't want to sign up for).

I vote for option 1, where we delete the SOAP code, increment the major version number, and document the breaking change in the README. We already have precedent for backporting bug fixes from master to older release branches, so if a user hits a bad bug against an old version of Qwiq we can backport a fix.

[rjmurillo]

We'll need some ability to write back with REST going forward. We can make a servicing change for 10.x to mark the SOAP classes as depreciated so folks get a heads up