Здравствуйте, Doc, Вы писали:

Doc>Здравствуйте, andyag, Вы писали:

A>>Подскажите пожалуйста какие могут быть подводные камни.

Doc>Я бы сделал механизм обновления клиентов и не держал бы более 2-3 версий API. Все же поддерживать 10 API это как-то путано.

Клиент — нативное iPhone-приложение. Там, насколько мне известно, невозможно заставить — можно только предложить. Поэтому "ну и фиг с вами" возможен только в самом крайнем случае — например для версий 3-месячной давности. По релизу раз в 2 недели, 3 месяца — это что-то типа 6-7 одновременных версий.

Doc>Бонус: не на все 100% по теме, но может натолкнуть на мысли:
Doc>Внутренний опыт компании Microsoft по автоматической сборке и непрерывной интеграции веб сервисов и приложений с помощью TFS 2012
Дядька там неприятный какой-то

Официально рекламируемый подход Microsoft для WCF — это такой не очень тривиальный набор правил, предполагающий разделение на ломающие и неломающие правки, с последующим уточнением и принятием решения — то ли делать что-то новое, то ли изменять существующее. Подход понятен, подход имеет смысл, но я слабо себе представляю такое на практике. Более того, этот подход предполагает заинтересованность в обратной совместимости ("расширения" ничего не ломают), требуя некоторого дополнительного мыслительного оверхеда от разработчика, а у меня такой заинтересованности нет. Более того, возникают вопросы вроде "а как бы мне так писать функциональные/интеграционные тесты, чтобы требования для всех актуальных версий сохранять". Мой подход "головой об стену" вполне тривиален и однозначен: есть возможность почти независимо чинить, тестировать и разворачивать любую из актуальных версий, т.к. это фактически десяток "никак не связанных" сервисов, опционально использующих одну общую библиотеку с бизнес-логикой. При этом у каждого из сервиса свой интерфейс, по необходимости — своя частичная реализация и свой набор функциональных тестов.