Что такое обратная совместимость
Это когда старая игра запускается на новой приставке
Совместимость — это когда что-то одно может работать с чем-то другим без дополнительных настроек, переделок или костылей.
Например, есть дизельное топливо. Оно совместимо с дизельными автомобилями — независимо от их марки, года выпуска, пробега или других параметров. А ещё можно приехать на своей машине на любую заправку с дизелем, а не искать специальную заправку только для определённой марки машин. Вот это всё — совместимость.
В ИТ чаще всего говорят про прямую и обратную совместимость, когда в одну сторону совместимость работает, а в другую — нет.
Когда совместимости нет
Допустим, на предприятии есть программа, которая обслуживает базу данных в нестандартном формате. Проходит время, разработчики увольняются и перестают поддерживать программу. Но программа нужна предприятию, поэтому ей продолжают пользоваться.
Чтобы код всегда оставался актуальным и чистым, используют рефакторинг. Про это у нас есть отдельная статья.
Спустя пять лет программа конкретно устарела: в ней нет поддержки современных удобных протоколов и она не работает на новых операционных системах. Но зато она работает со старой базой.
Предприятие ищет какое-то решение своей проблемы, но выясняется, что ни одна программа не совместима с её базой данных. Это ситуация, когда совместимости нет.
Обычная (или прямая) совместимость
Предприятие обращается за помощью к новым разработчикам: нужно сделать программу, которая умеет работать с нужным форматом баз данных. И, кроме этого, в программе должны быть все современные протоколы и поддержка современных операционок. Разработчики создают этот софт. Это прямая совместимость.
Прямая совместимость — это когда что-то одно может работать с другим. Это относительно простая задача для разработчика, потому что для неё достаточно добавить поддержку нужного формата данных или протоколов.
Обратная совместимость
А теперь представим другую ситуацию: разработчики не ушли с предприятия, а продолжили работать над проектом. В итоге за пять лет они придумали новую версию базы: тоже нестандартную, но более быструю. Но данные за пять лет всё ещё живут в старой базе данных, а переносить их нельзя.
Теперь перед программистами стоит противоречие:
Это обратная совместимость: новая версия программы поддерживает и новое, и старое.
Пример обратной совместимости — операционная система Windows. В каждой новой версии есть поддержка части программ, которые написаны для старых версий. Даже если вы попробуете запустить аудиоплеер, разработанный для Windows 95, в свежей Windows 10, то, вероятно, у вас это получится.
Также обратная совместимость позволяет нам взять игру для PlayStation 4 и запустить её на новой PlayStation 5 (скорее всего). А вот прямой совместимости у них нет: игра, написанная специально для PS5, вряд ли запустится на PS4.
В чём подвох
Обратная совместимость — головная боль для разработчиков. Ради полноценной поддержки старого формата иногда приходится жертвовать скоростью работы или надёжностью.
Например, в новой версии используется более современный протокол передачи данных. Но чтобы старые версии тоже смогли работать, разработчикам приходится поддерживать одновременно два протокола — новый и старый, каждый проверять на ошибки. Чем больше отличий в версиях — тем сложнее это поддерживать. Иногда для реализации старых технологий тратится намного больше ресурсов, чем для такой же работы — в новых.
Бесконечность проблемы обратной совместимости
(с)
Обратная совместимость применительно к аппаратным или программным системам означает способность успешно использовать интерфейсы и данные из более ранних версий системы. Этот принцип распространяется не только на программы, которые работают с файлами, созданными в более ранних версиях этих же программ, но и касается ситуаций работы со схожими алгоритмами. Например, Perl поддерживает обратную совместимость с другим языком — Awk, — который Perl был предназначен заменить.
Обратную совместимость легче выполнять, если предыдущие версии системы были разработаны с поддержкой встроенных функций, таких как хуки, плагины или API, которые позволяют добавлять новые возможности вашему софту, однако все из области backward compatibility (c упором на back) может стать головной болью для разработчиков.
Откажешься от нее совсем — расстроятся пользователи предыдущих версий систем и продуктов, вмиг потеряв весь парк накопленных гаджетов или программ. Обеспечишь полную обратную совместимость — станешь заложником прошлых решений, сделав свой продукт тяжелым, неповоротливым, или даже не способным на нужный прирост характеристик.
Разработчик каждый раз принимает трудное решение: должен ли продукт быть обратно совместимым. «Объективно правильного» решения здесь просто нет — в мире достаточно примеров успешной обратной совместимости и отказов от нее. Возможно, чей-то опыт поможет сделать вам правильный выбор прямо сейчас.
Давайте снова поменяем стандарт
Один из самых ярких примеров, когда об обратной совместимости решили забыть, это появление разъема USB 3.1 Type C (USB-C). Многие годы мы не ведали проблем: любой гаджет с разъемом micro- или miniUSB можно было воткнуть в любой соответствующий USB-порт. Но консорциум USB-IF создал разъем Type C, совершенно несовместимый механически ни с одним из сотен миллионов, а то и миллиардов смартфонов, кабелей, зарядных устройств и прочих гаджетов.
Еще одна проблема заключается в том, что не каждый USB-C кабель, порт, устройство и питание совместимы между собой: некоторые кабели с USB-C на обоих концах могут передавать лишь 5 Гбит/с, другие совместимы с 10 Гбит/с, а есть и те, что нельзя использовать для питания.
Ситуация привычная для тех, кто когда-то собирал себе компьютеры самостоятельно или занимался их апгрейдом. За последние 20–30 лет на наших глазах сменилось множество поколений шин и портов, почти каждое из которых не было обратно совместимо с предыдущими. Поменялись буквально все разъемы на материнской плате, и не по одному разу: сокеты процессоров, шины видеокарт и оперативной памяти, разъемы для подключения накопителей и периферии.
Нездоровая чехарда в мире процессоров продолжается до сих пор: вполне себе бодрые модели, которые гонять и гонять, через несколько лет уже нельзя поставить на новые материнские платы. Производителям трудно устоять перед соблазном регулярно делать бесполезными запасы железа у пользователей, заставляя их нести деньги на новые модели. Отсутствие обратной совместимости не греет душу, когда купленный три года назад процессор приходится менять на практически такой же, потому что умерла материнская плата.
Универсальный разъем, предназначенный для передачи данных и питания, способен стать единственным портом на устройстве — и в этом несомненный плюс USB Type-C. Можно смириться с отсутствием обратной совместимости в гаджетах, и даже отметить для себя плюсы (более высокую скорость передачи данных и иные параметры электропитания), но в сфере ПО болезненнее воспринимается несовместимость новых версий со старыми. Особенно это касается корпоративных продуктов, стоимость которых и влияние на бизнес-процессы слишком велики.
Геймдев
В экосистеме ПК игры обратно совместимы в течение десятилетий. Такие утилиты как DOSBox позволяют нам играть даже в самые ранние ПК-релизы. Фактор совместимости, при которой переход на новую версию системы с большой вероятностью не влечет за собой проблем, похоже, сыграл роль в текущем доминировании Windows. Да, в результате 32-битные версии Windows поддерживали запуск 16-битного программного обеспечения Windows и некоторый софт MS-DOS (а в 64-битных версиях, соответственно, работают 32-битные программы), но Microsoft получили огромную тяжелую платформу, в которой есть совместимость даже с ошибками.
А как дела у приставок?
Отчет Ars Technica показал, как пользователи Xbox One и Xbox 360 используют свои устройства. Интересно, что данные из отчета по приставке Microsoft совпадают с мнением корпорации Sony, которая не рассматривает обратную совместимость в PlayStation 4 как нечто важное. По мнению руководителя Sony Interactive Entertainment Europe Джима Райана, об этой функции больше говорят, чем реально пользуются. Хотя Sony действительно предоставила возможность скачать игры для PS1 и PS2 на PS4.
Некоторые сайты проводили свои собственные опросы в преддверии выхода Xbox One и PS4 — тогда было отмечено, что многие игроки заявляли о желании обратной совместимости. Microsoft привлекла большое внимание к обратной совместимости с Xbox One. Функция была в целом хорошо реализована, но сейчас не особо привлекает геймеров.
В линейках Nintendo DS и Wii также есть много примеров обратной совместимости.
Геймдевелоперы усилия компаний встретили более воодушевленно — больше не требуется изучать архитектуру с нуля, чтобы воспользоваться преимуществами нового консольного оборудования. Обратная совместимость позволяет относительно просто поддерживать релизы для всех устройств, созданных на основе общей архитектуры.
Обратная совместимость в языках
(с)
Каждый популярный язык программирования имеет ясную эволюцию, большую часть его жизни обозначенную версией: у вас есть Java 5, 6, 7 и т. д., PHP 5.1, 5.2, 5.3 и т. д. Каждая новая версия исправляет ошибки и добавляет функции, но если язык (или платформа) имеет фундаментальные изъяны, то разработчики либо избегают их (если могут), либо учатся жить с ними.
Разработчики языков получают много отзывов от программистов, использующих тот или иной язык программирования в своей работе. Кажется, что однажды выйдет версия языка, в которой все проблемы исчезнут. Но этого не происходит. Почему так? Один из вариантов — обратная совместимость.
У популярного PHP есть недостатки, и те, кто давно с ним работают, прекрасно знают, как можно обойти все ловушки и ямы языка. Теперь предположим, что в новой версии языка исправили все минусы, но потеряли обратную совместимость. В результате разработчик тратит время на обновление кода до актуальной версии PHP. То самое время, которое он мог бы потратить на выполнение запросов клиентов или внедрение новых функций.
Учитывая эти проблемы, понятен мотив тех, кто не хочет переходить на новую версию PHP, даже если она лучше, понятнее и безопаснее и т. д. Вы скажете, что это гипотетический пример. Возможно… Но в мире еще есть программисты, которые до сих пор работают на COBOL! Язык появился в 1958 году. К 1997 году активно использовалось около 240 миллиардов строк кода на COBOL, кодом на этом языке обрабатывалось около 90% финансовых транзакций в мире и 75% коммерческих транзакций. Самое интересное — это потрясающая совместимость языка: тот COBOL, который использовался в 60-х, может работать и на современном оборудовании.
Есть продукты, которые в принципе не могут поломать обратную совместимость, потому что это поставит на них крест. Например, Java: основная сфера применения этого языка — бизнес-приложения, по всему миру написано астрономическое количество строк кода, в том числе в огромных корпоративных кодовых базах. Код, написанный 20 лет назад, до сих пор работает. И если завтра выйдет версия Java, в которой разработчики накрутят фантастические фичи, но без обратной совместимости, то никто больше не станет инвестировать очень большие деньги в разработку серьезных — и дорогих — приложений. Так что Oracle придется либо всю жизнь тянуть за собой груз старых версий, либо открывать дорогу нововведениям, но при этом теряя большую долю клиентов. На третий вариант — поддерживать одновременно две ветки Java, с полноценным сопровождением и развитием — не согласится сама корпорация.
В свое время разработчики Python нарушили обратную совместимость, тем самым разозлив кучу пользователей. Большинство программистов не считало язык Python 2.x «ошибочным» или содержащим «фундаментальные изъяны». У них не было таких жалоб, какие появляются у разработчиков на PHP.
Сегодня сообщество языка разделено на два лагеря, при этом масса готовых библиотек под вторую версию не дает многим мигрировать на третью, хотя та и привнесла в язык ряд сильных улучшений. В результате закрепилось мнение, что «Python 3 — это худшее, что могло случиться с сообществом Python».
У проблемы есть и обратная сторона — Python 3 был выпущен в декабре 2008 года, но поддержка языка во фреймворке Django появилась только спустя пять лет.
Хотя нет 100% совместимости между C и C ++, но даже в C ++ есть обратная совместимость с очень ранними функциями языка (включая некоторые функции, унаследованные непосредственно от C).
Накопление технического долга
Иногда проблема возникает потому, что мы просто не в силах предсказать будущее. В 1981 году «Интернета» хватало всем и каждому — была описана первая широко используемая версия протокола IPv4, использующая 32-битные адреса, ограничивающие адресное пространство 4 294 967 296 возможными уникальными адресами.
4,3 миллиарда адресов IPv4 выглядели более чем достаточно для ARPANet. IPv6 появился в 1998 году (описан в RFC2460), но популярности протокол не снискал. Потребовалось более десяти лет, чтобы на проблему ограниченного количества адресов обратили внимание. И вот тогда стало понятно, что гигантская база разработанного и установленного программного и аппаратного обеспечения IPv4 требует сохранения обратной совместимости IPv6 с IPv4.
«Внезапно» выяснили, что IPv6 был разработан без полноценной совместимости с предыдущей версией — узел с поддержкой только IPv6 не может подключиться к узлу, работающему только по IPv4. Переход от IPv4 к IPv6 требовал «двухстековой» фазы, во время которой хост-компьютер взаимодействовал бы с обоими стеками протоколов одновременно, используя стек протокола IPv6 для взаимодействия с другими хост-компьютерами IPv6, а стек протокола IPv4 для взаимодействия с другими хост-компьютерами IPv4.
Некоторые коммутаторы, маршрутизаторы и устройства безопасности также оказались не совместимы с IPv6. Таким образом процесс перехода на IPv6 столкнулся со множеством проблем, решать которые предлагается разными способами. Ни одно из существующих решений нельзя назвать идеальным, но каждое из них найдет свое применение.
Философия обратной совместимости в ПО
Когда задумался, нужно ли в новой версии поддерживать совместимость (с)
В софте обратная совместимость, как правило, подразумевает сильное увеличение размеров файлов и всего приложения, но самое главное не это. Обратная совместимость обычно требует тащить за собой исторический багаж, что в интерпретируемых языках нередко приводит к заметным потерям в производительности.
При обратной совместимости раздувается кодовая база, усложняется архитектура приложения, затрудняется апгрейд приложений. Возникает желание отринуть старое и написать компактный, легкий код, использующий самые современные наработки.
Например, новая версия Skype больше не может устанавливать голосовые и видеосоединения с версиями под Windows XP. И, конечно, некоторые пользователи хотят проигнорировать новый релиз, предпочтя остаться на старом, но таком привычном.
Да, обратная совместимость сегодня считается одним из важнейших условий при разработке программных продуктов. Она позволяет пользователям наименее безболезненно — а значит, и комфортно — переходить на новые продукты. Производителям игровых приставок, например, важно обеспечивать обратную совместимость новых игр со старыми гаджетами, чтобы максимально расширять аудиторию потенциальных покупателей. Но при этом разработчикам труднее реализовывать новый уровень реалистичности графики и физики, что, по иронии, может снизить привлекательность системы для геймеров.
Мы сами периодически сталкиваемся со схожими вопросами. При написании облачного решения «горячего» хранения данных Hotbox можно было все полностью создать с «нуля» или использовать существующие наработки в Почте и Облаке Mail.Ru. Написание с нуля позволяет разом избавиться от всего накопившегося технического долга, однако это долго. Минус использования текущих наработок в том, что мы остаемся на языке Perl, для которого сложно находить новых разработчиков в связи с его не самой большой популярностью. Но плюсы этого решения существенно перевешивают: в этом языке у нас огромная экспертиза и наработанные годами инструменты. Так как было критично выпустить продукт в срок — мы решили остановиться на использовании Perl.
В результате получился продукт, который на данный момент нас полностью устраивает. В этом случае «обратная совместимость» вышла за пределы одного лишь сервиса — мы сделали совместимость не только с наработками в других проектах, но и с нашим собственным опытом. Осознание этого факта приводит к простой мысли: не всегда новый язык, новая версия программы или новый гаджет является универсальным решением поставленной перед вами задачи.
Постановка проблемы обратной совместимости
Как обычно, дадим смысловой определение «обратной совместимости», прежде чем начинать изложение.
Обратная совместимость — это свойство всей системы API быть стабильной во времени. Это значит следующее: код, написанный разработчиками с использованием вашего API, продолжает работать функционально корректно в течение длительного времени. К этому определению есть два больших вопроса, и два уточнения к ним.
Что значит «функционально корректно»?
Это значит, что код продолжает выполнять свою функцию — решать какую-то задачу пользователя. Это не означает, что он продолжает работать одинаково: например, если вы предоставляете UI-библиотеку, то изменение функционально несущественных деталей дизайна, типа глубины теней или формы штриха границы, обратную совместимость не нарушит. А вот, например, изменение размеров визуальных компонентов, скорее всего, приведёт к тому, что какие-то пользовательские макеты развалятся.
Что значит «длительное время»?
С нашей точки зрения длительность поддержания обратной совместимости следует увязывать с длительностью жизненных циклов приложений в соответствующей предметной области. Хороший ориентир в большинстве случаев — это LTS-периоды платформ. Так как приложение все равно будет переписано в связи с окончанием поддержки платформы, нормально предложить также и переход на новую версию API. В основных предметных областях (десктопные и мобильные операционные системы) этот срок исчисляется несколькими годами.
Почему обратную совместимость необходимо поддерживать (в том числе предпринимать необходимые меры ещё на этапе проектирования API) — понятно из определения. Прекращение работы приложения (полное или частичное) по вине поставщика API — крайне неприятное событие, а то и катастрофа, для любого разработчика, особенно если он платит за это API деньги.
Но развернём теперь проблему в другую сторону: а почему вообще возникает проблема с поддержанием обратной совместимости? Почему мы можем хотеть её нарушить? Ответ на этот вопрос, при кажущейся простоте, намного сложнее, чем на предыдущий.
Мы могли бы сказать, что обратную совместимость приходится нарушать для расширения функциональности API. Но это лукавство: новая функциональность на то и новая, что она не может затронуть код приложений, который её не использует. Да, конечно, есть ряд сопутствующих проблем, приводящих к стремлению переписать наш код, код самого API, с выпуском новой мажорной версии:
код банально морально устарел, внесение в него изменений, пусть даже в виде расширения функциональности, нецелесообразно;
новая функциональность не была предусмотрена в старом интерфейсе: мы хотели бы наделить уже существующие сущности новыми свойствами, но не можем;
наконец, за прошедшее после изначального релиза время мы узнали о предметной области и практике применения нашего API гораздо больше, и сделали бы многие вещи иначе.
Эти аргументы можно обобщить как «разработчики API не хотят работать со старым кодом», не сильно покривив душой. Но и это объяснение неполно: даже если вы не собираетесь переписывать код API при добавлении новой функциональности, или вы вовсе её и не собирались добавлять, выпускать новые версии API — мажорные и минорные — всё равно придётся.
NB: в рамках этой главы мы не разделяем минорные версии и патчи: под словами «минорная версия» имеется в виду любой обратно совместимый релиз API.
Напомним, что API — это мост, средство соединения разных программируемых контекстов. И как бы нам ни хотелось зафиксировать конструкцию моста, наши возможности ограничены: мост-то мы можем зафиксировать — да вот края ущелья, как и само ущелье, не можем. В этом корень проблемы: мы не можем оставить свой код без изменений, поэтому нам придётся рано или поздно потребовать, чтобы клиенты изменили свой.
Помимо наших собственных поползновений в сторону изменения архитектуры API, три других тектонических процесса происходят одновременно: размывание клиентов, предметной области и нижележащей платформы.
Фрагментация клиентских приложений
В тот момент, когда вы выпустили первую версию API, и первые клиенты начали использовать её — ситуация идеальна. Есть только одна версия, и все клиенты работают с ней. А вот дальше возможны два варианта развития событий:
Если платформа поддерживает on-demand получение кода, как старый-добрый Веб, и вы не поленились это получение кода реализовать (в виде платформенного SDK, например, JS API), то развитие API более или менее находится под вашим контролем. Поддержание обратной совместимости сводится к поддержанию обратной совместимости клиентской библиотеки, а вот в части сервера и клиент-серверного взаимодействия вы свободны.
Это не означает, что вы не можете нарушить обратную совместимость — всё ещё можно напортачить с заголовками кэширования SDK или банально допустить баг в коде. Кроме того, даже on-demand системы все равно не обновляются мгновенно — автор сталкивался с ситуацией, когда пользователи намеренно держали вкладку браузера открытой неделями, чтобы не обновляться на новые версии. Тем не менее, вам почти не придётся поддерживать более двух (последней и предпоследней) минорных версий клиентского SDK. Более того, вы можете попытаться в какой-то момент переписать предыдущую мажорную версию библиотеки, имплементировав её на основе API новой версии.
Если поддержка on-demand кода платформой не поддерживается или запрещена условиями, как это произошло с современными мобильными платформами, то ситуация становится гораздо сложнее. По сути, каждый клиент — это «слепок» кода, который работает с вашим API, зафиксированный в том состоянии, в котором он был на момент компиляции. Обновление клиентских приложений по времени растянуто гораздо дольше, нежели Web-приложений; самое неприятное здесь состоит в том, что некоторые клиенты не обновятся вообще никогда — по одной из трёх причин:
пользователь не может обновиться вообще, потому что его устройство больше не поддерживается.
В современных реалиях все три категории в сумме легко могут составлять десятки процентов аудитории. Это означает, что прекращение поддержки любой версии API является весьма заметным событием — особенно если приложения разработчика поддерживают более широкий спектр версий платформы, нежели ваше API.
Вы можете не выпускать вообще никаких SDK, предоставляя только серверное API в виде, например, HTTP эндпойнтов. Вам может показаться, что таким образом, пусть ваше API и стало менее конкурентоспособным на рынке из-за отсутствия SDK, вы облегчили себе задачу поддержания обратной совместимости. На самом деле это совершенно не так: раз вы не предоставляете свой SDK — или разработчики возьмут неофициальный SDK (если кто-то его сделает), или просто каждый из них напишет по фреймворку. Стратегия «ваш фреймворк — ваша ответственность», к счастью или к сожалению, работает плохо: если на вашем API пишут некачественные приложения — значит, ваше API само некачественное. Уж точно по мнению разработчиков, а может и по мнению пользователей, если работа API внутри приложения пользователю видна.
Конечно, если ваше API достаточно stateless и не требует клиентских SDK (или же можно обойтись просто автогенерацией SDK из спецификации), эти проблемы будут гораздо менее заметны, но избежать их полностью можно только одним способом — никогда не выпуская новых версий API. Во всех остальных случаях вы будете иметь дело с какой-то гребёнкой распределения количества пользователей по версиям API и версиям SDK.
Эволюция предметной области
Другая сторона ущелья — та самая нижележащая функциональность, к которой вы предоставляете API. Она, разумеется, тоже не статична и развивается в какую-то сторону:
Как правило, API абстрагирует некоторую более гранулярную предметную область. В случае нашего примера с API кофе-машин разумно ожидать, что будут появляться новые модели с новым API, которые нам придётся включать в свою платформу, и гарантировать возможность сохранения того же интерфейса абстракции — весьма непросто. Даже если просто добавлять поддержку новых видов нижележащих устройств, не добавляя ничего во внешний интерфейс — это всё равно изменения в коде, которые могут в итоге привести к несовместимости, пусть и ненамеренно.
Стоит также отметить, что далеко не все поставщики API относятся к поддержанию обратной совместимости, да и вообще к качеству своего ПО, так же серьёзно, как и (надеемся) вы. Стоит быть готовым к тому, что заниматься поддержанием вашего API в рабочем состоянии, то есть написанием и поддержкой фасадов к меняющемуся ландшафту предметной области, придётся именно вам, и зачастую довольно внезапно.
Дрифт платформ
Наконец, есть и третья сторона вопроса — «ущелье», через которое вы перекинул свой мост в виде API. Код, который напишут разработчики, исполняется в некоторой среде, которую вы не можете контролировать, и она тоже эволюционирует. Появляются новые версии операционной системы, браузеров, протоколов, языка SDK. Разрабатываются новые стандарты и принимаются новые соглашения, некоторые из которых сами по себе обратно несовместимы, и поделать с этим ничего нельзя.
Как и в случае со старыми версиями приложений, старые версии платформ также приводят к фрагментации, поскольку разработчикам (в том числе и разработчикам API) объективно тяжело поддерживать старые платформы, а пользователям столь же объективно тяжело обновляться, так как обновление операционной системы зачастую невозможно без замены самого устройства на более новое.
Самое неприятное во всём этом то, что к изменениям в API подталкивает не только поступательный прогресс в виде новых платформ и протоколов, но и банальная мода и вкусовщина. Буквально несколько лет назад были в моде объёмные реалистичные иконки, от которых все отказались в пользу плоских и абстрактных — и большинству разработчиков визуальных компонентов пришлось, вслед за модой, переделывать свои библиотеки, выпуская новые наборы иконок или заменяя старые. Аналогично прямо сейчас повсеместно внедряется поддержка «ночных» тем интерфейсов, что требует изменений в большом количестве API.
Политика обратной совместимости
Итого, если суммировать:
Опишем кратко эти решения и ключевые принципы их принятия.
Как часто выпускать мажорные версии API.
Это в основном продуктовый вопрос. Новая мажорная версия API выпускается, когда накоплена критическая масса функциональности, которую невозможно или слишком дорого поддерживать в рамках предыдущей мажорной версии. В стабильной ситуации такая необходимость возникает, как правило, раз в несколько лет. На динамично развивающихся рынках новые мажорные версии можно выпускать чаще, здесь ограничителем являются только ваши возможности выделить достаточно ресурсов для поддержания зоопарка версий. Однако следует заметить, что выпуск новой мажорной версии раньше, чем была стабилизирована предыдущая (а на это как правило требуется от нескольких месяцев до года), выглядит для разработчиков очень плохим сигналом, означающим риск постоянно сидеть на сырой платформе.
Какое количество мажорных версий поддерживать одновременно.
Что касается мажорных версий, то теоретический ответ мы дали выше: в идеальной ситуации жизненный цикл мажорной версии должен быть чуть длиннее жизненного цикла платформы. Для стабильных ниш типа десктопных операционных систем это порядка 5-10 лет, для новых и динамически развивающихся — меньше, но всё равно несколько лет. Практически следует смотреть на долю потребителей, реально продолжающих пользоваться версией.
Какое количество минорных версий (в рамках одной мажорной) поддерживать одновременно.
Для минорных версий возможны два варианта:
Более подробно мы рассмотрим эти вопросы в следующих главах. Дополнительно в разделе III мы также обсудим, каким образом предупреждать потребителей о выходе новых версий и прекращении поддержки старых, и как стимулировать их переходить на новые версии API.
Это черновик будущей главы книги о разработке API. Работа ведётся на Github.
Англоязычный вариант этой же главы опубликован на medium. Я буду признателен, если вы пошарите его на реддит — я сам не могу согласно политике платформы.