Update 20100224 I really don't need some lame definitions from some vendor website. What I am looking for is practical implementation and challenges faced in the daily IT/business cycle for people who actually implement this stuff.
More stuff follows:
No retirement strategy has been created/adopted: Obviously one needs to be created. I am interested in how you create this strategy and sell it to management. What are all of the costs/benefits you look at? Do you do a BE analysis on customer recoding requirements vs. Internal support requirements? Do you assign a $ value to internal support costs of ancient API's?
Production IT support implications: How have you worked with your production IT groups to deploy your strategy. What do they like and what makes them crazy?
Software: What do you software guys like to do, what does the business tell them to do and what do they actually do? What works best for them?
QA: How do QA like to handle testing. ex. If you have created a single service that handles multiple versions does QA do full regression for everything every time a change is made to one of the versions?
DBA's: How do your dba's deal with the common procs that are critical to the data logging for adding a field to an xml response? Do you have a single proc or do you do branch things and segment based on schema or other?
original note
I am collecting info on the pros and cons of different web services versioning strategies. The business has not yet determined a strategy for web service retirement, and my web services do change significantly due to product changes, customer requirement changes and our partner integration changes.
I am looking for a pros/cons for maintaining independent stand alone or multiple/integrated versions over time and how this affects the business including developer support/developer integration resources, production IT support, Software, QA & DBA's.
Any insight, experiences, resources or ideas are appreciated.