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

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

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

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

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

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


backwards-compatibility compiler-version
person Phil Miller    schedule 04.10.2009    source источник
comment
Мне кажется, это деловое решение (больше, чем техническое); но я не знаю, почему вы предоставляете и/или не предоставляете программное обеспечение клиентам, и я не знаю, почему некоторые клиенты хотят использовать старые компиляторы, и я не знаю, каковы цифры (т.е. сколько клиентов и /или какая доля клиентов).   -  person ChrisW    schedule 04.10.2009
comment
Видите ли, мы университетская исследовательская лаборатория. Наши клиенты не платят нам, они цитируют нас в газетах. Таким образом, «деловое соображение» заключается в том, сможем ли мы быстрее получить лучшие результаты, избавившись от бремени поддержки, и поможет ли использование нашего программного обеспечения другими группами более быстрая разработка или будет затруднено из-за ограничения их выбора инструментов.   -  person Phil Miller    schedule 04.10.2009
comment
Мы столкнулись с проблемой, что MSVC является архаичным компилятором C — он не поддерживает полезные функции C99 (например, назначенные инициализаторы). Трудно решиться отказаться от этого - к сожалению.   -  person Jonathan Leffler    schedule 08.10.2009
comment
@Jonathan: Это то, с чем нам приходится мириться, но на самом деле это не такая уж большая проблема. 99% нашего кода — это C++, и лишь некоторые биты уровня переносимости в C. И мы, вероятно, можем уменьшить их распространение. Было бы неплохо, если бы // комментарии работали везде — ежедневный перерыв в сборке в Windows, когда мы облажались, раздражает.   -  person Phil Miller    schedule 08.10.2009

Ответы (2)


arrow_upward
3
arrow_downward

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

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

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

person Imagist    schedule 04.10.2009

arrow_upward
2
arrow_downward

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

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

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

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

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

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

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

person scope_creep    schedule 04.10.2009