Технические соображения по поводу отказа от поддержки старых версий компилятора?

Question

Я работаю над проектом, который распространяется бесплатно как в исходном, так и в двоичном виде, поскольку многим нашим пользователям необходимо скомпилировать его специально для своей системы. Необходима определенная степень поддержки обратной совместимости со старыми хост-системами и, прежде всего, их компиляторами.

Некоторым из самых жестоких из них, таким как GCC 3.2 (2003!), ICC 9, MSVC (почти заброшенное ПО, а не C ++!) И компилятору Sun (в какой-то старой версии, которая нам все еще нужна), не хватает поддержки языка функции, которые сделали бы разработку намного проще. Определенно есть также случаи, когда предоставление пользователям возможности придерживаться этих компиляторов обходится им очень дорого, что противоречит целям того, что мы предоставляем.

Итак, в какой момент мы говорим, что достаточно достаточно? Я вижу несколько аргументов для прекращения поддержки конкретного компилятора:

• Низкая производительность сгенерированного кода (относительно более новых версий, спросили о здесь )
• Отсутствие поддержки языковых функций
• Плохая доступность в системах разработки (больше для проприетарного, чем GCC, но есть проблемы с системным администратором при получении старого GCC)
• Возможность нефиксированных ошибок (мы выделили ICE в ICC и xlC, что еще может скрываться?)

Я уверен, что скучал по некоторым другим, и я не уверен, как их весить. Итак, какие аргументы я пропустил? Какие другие технические соображения вступают в игру?

Примечание. Ранее этот вопрос был сформулирован более широко, что привело к тому, что многие респонденты указали, что принятие решений - это, по сути, бизнес-процесс, а не процесс разработки. Я знаю о «деловых» соображениях, но это не то, что я ищу здесь. Я хочу услышать опыт людей, которые должны были поддерживать старые компиляторы или сделали выбор, чтобы отбросить их, и как это повлияло на их разработку.

Answer 1

Ваш вопрос концептуально такой же, как и у веб-разработчиков, которые хотят знать, когда им следует прекратить поддержку Internet Explorer 6. Ответ заключается в том, что вы должны провести исследование.

1. Сколько людей используют старые компиляторы?
2. Сколько пользуетесь новыми?
3. Сколько будет желающих обновить?
4. Сколько пользователей вы потеряете? (Это можно рассчитать по ответам на 1, 2 и 3).
5. Сколько времени и работы сэкономит вам отказ от поддержки старых компиляторов?

В основном ваше решение сводится к сравнению ответов на 4 и 5. Похоже, что это проект с открытым исходным кодом из вашего описания, но если это бизнес, вы можете сравнить его численно (если потерянные деньги меньше, чем сэкономленные деньги) Оставь поддержку). Если это не бизнес, это немного сложнее, так как вы должны угадать человеческие затраты, которые могут быть немного хитрыми.

Answer 2

Я не думаю, что это что-то особенное, чтобы повысить эффективность старой технологии компилятора. Это бизнес-решение, и оно действительно сводится к тому, хотите ли вы сохранить своих клиентов или потерять их. Клиенты не занимаются технологиями, они занимаются бизнесом и бизнес-решениями.

В идеале вы хотите определить какую-то метрику, основанную на том, сколько клиентов вы иметь, против различных версий компилятора, которые они используют, против стоимости поддержание определенных версий каждого типа компилятора.

По сути, вам действительно нужно быть осторожным, когда и как вы собираетесь рассказать своему клиенту основание, что вы собираетесь удалиться часть вашего набора продуктов. Как ты им и скажешь. Просто брось его на колени. Запланируйте это.

Вам нужна внутренняя утвержденная контролируемая политика, и начните ее развертывать, возможно, рассказывая их на собраниях групп пользователей, а затем убедитесь, что у вас есть достаточно времени (2 года хорошо, позвольте клиенту завершить текущие реализации (1 год) плюс немного провисания, прежде чем вы начнете внедрять, и у вас есть структура поддержки, чтобы помочь клиенту мигрировать во времени.

То, как вы планируете это, будет определять реакцию ваших клиентов. Прошло несколько лет, я работал в Дом программного обеспечения, который продал действительно сложный продукт высокого класса для управления электрическими сетями. Продукт продается за 2 миллиона фунтов стерлингов за полный пакет, и каждый клиент подписывает 25-летний контракт поддержки. Каким-то образом мы решили рационализировать аппаратное обеспечение. Мы были предлагая его на AIX, Solaris, Tru64 и HPUX. Но по причине мы решили рационализировать это на AIX, который, я думаю, мы заключили сделку. Во всяком случае, один из клиентов, который был магазин Solaris очень расстроился из-за этого, и затем в течение следующих 4 лет мы никогда не слышали от них ни слова. Нет телефонных звонков, пропатчен, на сайтах проверок. Ничего такого.

Причина, по которой мы решили изменить это, так как мы делали проект 6 сигм, и это указывало на то, что мы сэкономит около 19 миллионов фунтов стерлингов в год, купив рационализацию инфраструктуры для AIX и NT. Но в в конце концов, мы закончили с одним из наших основных клиентов, практически уничтожив сообщество пользователей.

Решение было принято поспешно, и оно имело обратный эффект. Поэтому я думаю, что ваша лучшая идея - спланировать это.

Answer 3

Ну, обычный способ сделать это сначала спросить. Я предполагаю, что у вас есть список рассылки веб-страницы или что-то для этого. Поэтому спросите: на кого это повлияет и насколько сложно будет выполнить обновление, если мы откажемся от поддержки любого из этих компиляторов. После этого вы поймете, стоит ли продолжать поддерживать эти компиляторы.

Также может быть полезно отметить последнюю рабочую версию для каждой версии компилятора, для которой вы решили отказаться от поддержки, чтобы любой, кто действительно заботится, мог продолжать использовать эту старую версию.